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ABSTRACT 

The  design  and  execution  of  a  networked  virtual  environment  (NVE)  are 
challenging  tasks  made  even  more  difficult  by  the  fact  that  NVEs  are  becoming  more 
complex  and  difficult  to  manage.  In  a  distributed  environment,  each  simulation  not  only 
computes  its  own  behaviors  and  publishes  them  to  the  network,  but  it  must  accurately 
represent  all  other  entities  participating  in  the  NVE.  To  simplify  this  task,  this  thesis 
implements  method  to  make  distributed  simulations  dynamically  extensible,  flexible, 
specific,  and  consistent.  Bamboo  provides  the  ability  to  dynamically  extend  the  virtual 
environment  by  defining  a  convention  by  which  plug  in  modules  can  be  added  during 
simulation  runtime.  The  HLA  provides  the  network  communication  layer  that  transports 
entity  state  updates  to  all  members  of  the  distributed  simulation.  These  two  tools  combine 
to  create  a  unique  solution  to  problems  inherent  in  designing  modern  networked  virtual 
environments.  The  implementation  is  dynamically  extensible  which  increases  the  flexibility 
implementers  have  in  designing  virtual  environments.  The  HLA  transports  the  entity 
updates  and  the  module  name  that  must  be  used  to  represent  the  entity.  This  method 
allows  programmers  to  design  only  their  module  because  modules  representing  other 
entities  will  load  as  needed  during  the  execution.  This  method  of  implementing  virtual 
environments  that  promises  to  streamline  the  design  and  implementation  process. 
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I.         INTRODUCTION 


A.         MOTIVATION 


The  design  and  execution  of  a  networked  virtual  environment  (NVE)  are 
challenging  tasks  made  even  more  difficult  by  the  fact  that  NVEs  are  becoming  more 
complex  and  difficult  to  manage.  In  a  distributed  environment,  each  simulation  not  only 
computes  its  own  behaviors  and  publishes  them  to  the  network,  but  it  must  accurately 
represent  all  other  entities  participating  in  the  NVE.  To  simplify  this  task,  a  method  must 
be  devised  to  make  distributed  simulations  dynamically  extensible,  flexible,  specific,  and 
consistent.  A  dynamically  extensible  virtual  environment  would  allow  users  to  change  the 
executable  at  runtime  to  whatever  state  is  specified  by  the  user.  The  challenge  is  to  design 
a  system  that  allows  users  to  design  entity  definitions  that  can  be  loaded  and  unloaded 
during  execution.  With  true  dynamic  extensibility  comes  flexibility,  and  designers  are  not 
tied  to  compile  time  determinations  of  behavior.  Consistency  in  this  sense  means  all  sites 
participating  in  the  NVE  need  the  same  definitions  for  each  entity  and  the  terrain  model 
being  used.  Finally,  the  designer  of  a  specific  simulation,  such  as  a  tank  simulator,  should 
not  need  to  design  the  other  entities  that  will  be  depicted  in  the  simulation.  These  remote 
objects  should  be  program  objects  that  can  be  added  as  needed  during  execution.  This 
approach  will  allow  NVE  implementers  and  programmers  the  flexibility  to  design  and  run 
NVEs  in  real  time  without  the  problems  of  inflexibility  and  static  design  inherent  to 
distributed  simulation. 

B.         BACKGROUND 

There  are  many  examples  of  NVEs  that  use  different  methods  of  communicating 
entity  state  and  ensuring  consistency  between  simulation  locations.  Examples  include 
DIVE  [1]  and  BRICKNET  [2].  These  systems  share  one  characteristic.  They  are  defined 
at  compile  time  and  are  unchangeable  during  execution.  They  allow  dynamic  allocation  of 
memory  but  the  definitions  of  each  entity  are  defined  at  compile  time  and  are 
unchangeable. 

The  DIVE  core  uses  peer-to-peer  communication  between  shared  virtual  worlds. 
All  DIVE  processes  connected  to  the  same  world  are  identical.  A  DIVE  process  can 
choose  what  world  it  is  a  part  of  but  it  can  only  be  a  member  of  one  world  at  a  time. 
DIVE  is  limited  by  the  paradigm  of  distributed,  shared  memory.  This  paradigm  creates 
significant  network  traffic  trying  to  keep  the  shared  memory  consistent  from  process  to 
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process.  While  DIVE  shared  virtual  worlds  may  change  during  runtime,  the  method  of 
communication  and  the  abilities  of  the  system  are  previously  defined  and  are  not  extensible 
at  runtime. 

BRICKNET  allows  the  exchange  of  objects  and  object  updates  through 
BRICKNET  servers.  While  it  does  distribute  processing  on  multiple  servers,  entities 
require  the  server  to  update  state  and  define  behavior.  Workstations  are  primarily  used  to 
render  the  graphics  for  the  user.  Furthermore,  BRICKNET  object  updates  are  predefined 
and  the  update  protocol  cannot  be  modified. 

Finally,  distributed  interactive  systems  (DIS)  like  NPSNET  [3]  are  designed  on  the 
premise  that  each  site  could  build  their  own  simulation  and  choose  how  to  represent  each 
type  of  entity  without  regard  to  the  consistency  of  this  representation  across  the  network. 
Each  site  could  have  its  own  terrain  model  and  its  own  representations  for  each  entity 
type.  Because  of  these  inconsistencies,  DIS  simulations  are  plagued  with  discrepancies 
between  entity  position  and  orientation  and  line  of  site  computations  related  to  the  terrain 
models.  DIS  is  highly  enumerated  and  the  packets  containing  entity  state  are  large  and 
mostly  redundant.  These  inconsistencies  complicate  interactions  between  entities  because 
the  terrain  may  provide  different  line  of  sight  computations  from  one  simulation  to  the 
next.  Additionally,  the  actual  polygonal  representation  and  behaviors  of  the  entity  may  not 
be  consistent  among  workstations  in  the  distributed  simulation.  This  causes  excess 
network  traffic  to  solve  simple  interactions  between  entities  and  keep  entity  state  updated 
accurately  between  simulation  sites. 

Until  now,  there  was  no  way  to  ensure  all  simulation  sites  had  the  proper 
polygonal  and  behavioral  representation  for  all  entities  participating  in  the  virtual 
environment.  A  new  system,  Bamboo  [4],  provides  such  a  capability  by  providing 
simulations  a  framework  to  dynamically  load  and  unload  program  modules  as  the  situation 
changes  in  the  virtual  environment.  High  Level  Architecture  (HLA)  [5]  replaces  DIS  and 
provides  the  network  communication  capabilities.  By  implementing  the  simulation  as  a 
group  of  program  modules,  designers  solve  the  problem  of  ensuring  that  every  site  running 
in  the  NVE  is  consistent  with  every  other.  The  designer  just  ensures  every  participant  in 
the  NVE  knows  the  network  location  of  all  the  program  modules  making  up  the  NVE. 
Then,  as  the  virtual  world  executes,  each  site  loads  and  unloads  modules  as  needed.  All 
simulation  sites  have  the  same  representations  for  each  entity  as  well  as  its  associated 
behaviors  and  controls. 

This  thesis  describes  an  implementation  that  uses  Bamboo  to  handle  the  dynamic 
nature  of  modern  NVEs,  and  HLA  to  handle  the  communication  between  each  simulation 
site.   The  following  sections  provide  an  overview  of  Bamboo  and  HLA  features  and  how 
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they  apply  to  this  implementation.    Later  chapters  provide  a  detailed  description  of  both 
systems. 

C.        BAMBOO 

Bamboo  enables  dynamically  scaleable  virtual  environments  hosted  on  a  network. 
It  achieves  this  goal  by  an  efficient  implementation  that  provides  direct  support  for  the  key 
issues  pertaining  to  VE  development.  These  issues  include  dynamic  extensibility,  module 
dependency,  and  event  handling  [4].  Bamboo's  most  notable  feature  is  its  ability  to 
dynamically  extend  its  capabilities  during  run  time.  It  achieves  this  goal  by  implementing  a 
plug-in  metaphor  similar  to  that  used  by  commercial  packages  like  PhotoShop  [6]  and 
Netscape  [7].  In  addition  to  the  plug-in  metaphor,  Bamboo  implements  a  system  that 
allows  the  user  to  extend  the  executable  through  a  series  of  callbacks  that  a  newly  added 
module  allocates  at  load  time.  The  event  handler  simply  provides  an  abstraction  for 
handling  system-generated  events.  The  event  handler  uses  the  callback  handler  to  notify 
registered  parties  of  an  event.  Bamboo  receives  this  notification  as  a  callback.  Module 
dependency  provides  a  system  to  ensure  that  modules  which  are  required  by  other 
modules  are  loaded  first  before  the  depending  module.  Bamboo  uses  callback  handlers  so 
multiple  callbacks  respond  to  a  single  event.  This  is  a  cursory  introduction  to  the  features 
and  capabilities  of  Bamboo.  Chapter  two  provides  a  detailed  description  of  the  Bamboo 
system. 

D.  HIGH  LEVEL  ARCHITECTURE 

The  High  Level  Architecture  (HLA)  is  the  Department  of  Defense  standard  for 
simulation  interoperability  [5].  HLA  is  not  software.  It  is  an  architecture  that  provides 
standard  methods  of  defining  how  distributed  simulations  will  communicate.  It  is  a  set  of 
specifications  that  define  data  objects.  These  standards  are  specified  in  the  HLA  Interface 
Specification  and  the  Object  Model  Template  (OMT).  The  HLA  Interface  Specification 
defines  the  interface  between  the  simulation  and  the  software  that  will  provide  the  network 
and  simulation  management  services.  The  Runtime  Infrastructure  (RTI)  is  the  software 
that  provides  these  services.  The  OMT  prescribes  a  common  method  for  recording  the 
information  that  will  be  produced  and  communicated  by  each  simulation  participating  in 
the  distributed  exercise.  This  discussion  of  HLA  is  continued  in  detail  in  Chapter  3. 

E.  THESIS  ORGANIZATION 

This  thesis  is  organized  into  the  following  chapters: 


• 


• 


Chapter  I:  Introduction.  Outlines  the  organization  of  the  thesis  and  addresses 
the  significance  of  introducing  and  evaluating  a  new  method  for  implementing 
a  networked  virtual  environment. 

Chapter  II:  Bamboo.  Discusses  in  detail  the  current  implementation  of 
Bamboo  and  how  its  capabilities  are  suited  for  a  networked  virtual 
environment  implementation. 

Chapter  III:  High  Level  Architecture.  Discusses  in  detail  the  current 
implementation  of  the  HLA  and  how  its  capabilities  are  suited  for  a  networked 
virtual  environment  implementation.  This  chapter  includes  a  detailed 
discussion  of  the  run  time  infrastructure  (RTI)  and  how  its  capabilities  are 
exploited  in  this  implementation. 

Chapter  IV:  Implementation.  Describes  the  development  of  the  experimental 
virtual  environment  that  illustrates  the  power  of  combining  Bamboo  and  HLA. 

Chapter  V:  Results  and  Limitations.  Describes  performance  results  for  the 
implementation  and  certain  limitations  discovered  during  development. 

Chapter  VI:  Conclusions  and  Recommendations.  Discusses  the  significance  of 
the  results  and  gives  ideas  as  to  future  work  that  should  be  completed  in  this 
area. 


II.       BAMBOO 


A.  INTRODUCTION 

Bamboo  enables  dynamically  scalable  virtual  environments  hosted  on  a  network 
[4].  It  achieves  this  goal  by  an  efficient  implementation  that  provides  direct  support  for 
the  key  issues  pertaining  to  VE  development.  These  issues  include  dynamic  extensibility, 
event  handling,  and  module  dependency.  By  addressing  these  issues,  Bamboo  provides 
the  ability  for  the  system  to  dynamically  configure  itself  during  runtime.  Specifically,  this 
framework  provides  the  ability  to  discover  simulation  objects  on  the  network  at  runtime 
and  automatically  load  the  correct  module  to  represent  the  entity. 

B.  DYNAMIC  EXTENSIBILITY 

Bamboo's  most  notable  feature  is  its  ability  to  dynamically  extend  its  capabilities 
during  run  time.  It  achieves  this  goal  by  implementing  a  plug-in  metaphor,  then  extends 
the  idea  by  adding  module  dependency,  a  generalized  method  of  extending  the  executable 
and  a  generalized  event  handler. 

1.    Dependency 

Bamboo  extends  the  plug-in  metaphor  by  adding  inter-module  dependencies. 
Tracking  inter-module  dependencies  could  be  complex.  Fortunately,  as  Bamboo  loads 
each  module,  it  verifies  that  dependent  modules  load  first.  If  they  are  not  loaded,  it 
automatically  loads  them  without  specific  interaction  with  the  user.  Using  Figure  1  as  an 
example,  assume  M3  is  already  loaded.  If  M4  loads  later,  the  system  verifies  the  presence 
of  M2  in  memory.  Bamboo  loads  M2  if  it  is  not  in  memory.  As  M2  is  being  loaded 
Bamboo  verifies  the  presence  of  Ml.  M4  finally  loads  because  Bamboo  verified  all  its 
dependencies  [4]. 


Figure  1:  Module  Dependency  View 


2.  Extending  the  Executable 


Dynamic  loading  of  program  modules  does  not  in  itself  ensure  dynamic 
extensibility.  Bamboo  uses  a  callback  handler  that  allows  each  module  to  attach  and 
remove  itself  from  the  process's  execution  loop  when  being  paged  in  and  out  of  memory. 
The  callback  handler  derives  from  objects  that  can  be  named  so  it  is  easily  located  and 
manipulated.  The  callback  itself  is  recursive  and  provides  two  callback  handlers,  one  just 
before  callback  execution  and  one  directly  after.  This  allows  grouping  of  like 
functionality.  For  example,  rendering  engines  implement  some  form  of  app,  cull  and  draw 
as  a  pipeline.  Users  refer  to  surrounding  areas  as  pre  and  post  app,  pre  and  post  cull,  and 
pre  and  post  draw.  The  executable  begins  to  resemble  a  tree  of  callbacks.  Figure  2 
illustrates  how  using  callbacks  and  callback  handlers  to  extend  the  executable  begins  to 
resemble  a  tree  of  callbacks.  For  instance,  a  user  module  may  load  itself  and  depend  to 
the  visual  and  keyboard  modules.  At  load  time,  the  user  module  defines  callbacks  that 
provide  execution  time  for  the  logic  in  the  module.  Furthermore,  any  pruning  or  pausing 
of  sub-trees  automatically  includes  its  children.  Therefore  if  a  callback  handler  is  deleted, 
all  of  its  associated  callbacks  are  also  deleted  without  specific  user  interaction. 


Visual  Module 


Event  Handler  Module 
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User  Module 


Figure  2:  Extending  the  Executable 
3.  Event  Handling 

The  event  handler  simply  provides  an  abstraction  for  handling  system-generated 
events.  The  event  handler  uses  the  callback  handler  to  notify  registered  parties  of  an 
event.  Bamboo  receives  this  notification  as  a  callback.  Bamboo  uses  callback  handlers  so 
multiple  callbacks  respond  to  a  single  event.  For  example,  a  module  that  captures 
keyboard  events  would  monitor  the  keyboard  in  a  separate  thread  listening  for  keys 
identified  by  the  user.  In  figure  2,  the  Event  Handler  Module  has  multiple  callbacks  on 
two  separate  keys.  When  a  key  is  pressed,  then  the  callbacks  are  executed  in  the  order 
specified. 

C.         BAMBOO  CONCLUSION 


Bamboo  improves  on  the  plug-in  metaphor  in  three  distinct  ways.  It  provides  a 
convention  for  the  definition  of  program  modules.  Second,  it  generalizes  a  method  to 
extend  the  executable,  and  third,  it  provides  a  method  to  build  dependencies  between 
modules.  Using  these  features,  Bamboo  overcomes  many  of  the  pitfalls  of  monolithic 
virtual  environment  architectures  by  providing  modular  components  and  a  dynamically 
extensible  runtime  executable. 


III.     HIGH  LEVEL  ARCHITECTURE 

A.  INTRODUCTION 

The  High  Level  Architecture  (HLA)  provides  a  common  architecture  for  reuse  and 
interoperation  of  simulations.  This  means  that  simulations  designed  for  a  specific  purpose 
may  be  reused  in  a  different  application  using  the  HLA  concept  of  a  federation:  a 
composable  set  of  interacting  simulation  participants  -  federates.  The  intent  is  to  provide 
a  standard  architecture  under  which  simulations  are  designed  so  that  they  can  be  reused 
thereby  reducing  the  time  and  cost  required  creating  a  new  environment  for  a  new 
purpose.  [5] 

The  Object  Model  template  (OMT)  [8],  HLA  rules  [9]  and  the  Interface 
Specification  (IF  Spec)  [10]  define  the  HLA  standard.  A  final  component  of  the  HLA  is 
the  Runtime  Infrastructure  (RTI).  The  OMT  describes  the  essential  sharable  elements  of 
the  simulation  or  federation  in  'object'  terms.  In  the  HLA  sense,  objects  are  collections  of 
attributes  that  describe  simulation  entity  state  that  are  communicated  between  federates 
operating  in  the  federation.  Second,  the  IF  Spec  describes  the  runtime  services  provided 
to  each  federate  by  the  RTI.  The  RTI  is  the  software  component  of  the  HLA  that 
supports  the  exchange  of  data  defined  by  the  OMT  component.  Finally,  The  HLA  rules 
summarize  the  key  principles  behind  the  HLA. 

B.  OBJECT  MODEL  TEMPLATE 

The  HLA  is  designed  to  facilitate  interoperability.  Hence,  the  OMT  is  designed  to 
provide  a  means  for  open  information  sharing  across  the  simulation  community.  The 
OMT  does  not  constrain  the  content,  but  provides  a  streamlined  format  for 
communicating  to  the  other  users,  who  may  reuse  the  simulation,  and  the  data  inputs  and 
outputs  of  the  simulation.  The  HLA  specifies  two  types  of  object  models:  the  HLA 
Federation  Object  Model  (FOM)  and  the  HLA  Simulation  Object  Model  (SOM).  The 
FOM  is  a  specification  of  the  exchange  of  public  data  among  the  participants  in  a  HLA 
federation.  Those  participants  are  called  federates.  The  HLA  FOM  describes  the  set  of 
objects,  their  attributes  and  interactions  that  are  shared  between  federates  in  a  federation. 
The  SOM  describes  the  simulation  (federate)  in  terms  of  the  types  of  objects,  attributes, 
and  interactions  it  can  offer  to  future  federations. 


1.  Federation  Object  Model 

The  FOM  requires  information  concerning  the  object  classes,  object  interactions, 
class  attributes,  interaction  parameters  and  a  lexicon  describing  each  of  the  above  [8]. 

a.  Object  Class  Structure  Table 

Each  object  class  must  be  named  and  its  relationship  to  other  classes  must 
be  defined.  All  classes  must  be  defined  and  described  in  the  lexicon.  The  result  is  a  table 
similar  to  Table  1  [8]. 


Object  Class  Structure  Table 

<class>(<ps>) 

[<class>  (<ps>)] 

[<class>  (<ps>)] 

[<class>  (<ps>)J  [,<class>  (<ps>)l*l         [<ref>] 

|<class>  (<ps>)] 

[<class>  (<ps>)]  [,<class>  (<ps>)]*l  I<ref>] 

._ 

|<class>  (<ps>)l 

[<class>  (<ps>)]  [,<class>(<ps>)]*l  [<re£>] 

[<class>(<ps>)] 

[<class>(<ps>)l 

[<class>  (<ps>)l  [,<class>  (<ps>)]*l  [<ref>] 

[<class>  (<os>)l 

|<class>  l<ps>)]  [,<class>  (<ps>)l*l  |<ref>] 

<class>(<ps>) 

[<class>  (<ps>)] 

(<c!ass>(<DS>)l 

[<class>  (<ds>)1  l.<class>  (<ns>)l'l  l<ref>l 

[<class>  (<ps>)l 

[<class>(<ps>)]  [.<class>(<ps>)],l[<a,e£>l 

- 

- 

- 

~ 

Air  Vehicles) 

Fixed  Wing  (S) 

Fighter-Attack  (S) 

F-14  (PS) 

F-16(PS) 

F-18(PS) 

Bomber  (S) 

B-IB(PS) 

B-2  (PS) 

Roup,  Wins  (PS) 

Table  1:  Object  Class  Structure  Table 

This  table  shows  the  object  model  used  in  a  federation.  Class  Air  Vehicle  is  the  base  class 
for  all  flying  entities.  Class  Fixed  Wing  and  Rotary  wing  inherit  from  Air  Vehicle,  while 
Fighter-Attack  and  Bomber  inherit  from  Fixed  Wing.  Then  F-14,  F-16,  etc.  describe  the 
specific  types  of  aircraft  depicted  in  the  federation.  The  (P),  (S)  and  (PS)  stand  for 
publishable,  subscribable  and  both,  respectively.  This  means  that  individual  federates  can 
request  -  subscribe  -  certain  object  attributes  from  the  federation.  A  federate  may  also 
provide  -  publish  -  object  attributes  to  the  federation.  If  a  federate  represents  an  entity 
that  must  interact  with  entities  of  the  same  type,  that  federate  might  publish  and  subscribe 
to  the  same  Object  Class. 
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b.  Object  Interaction  Table 

The  object  interaction  table  shows  the  interaction  class  structure  for  the 
federation.  Table  2  shows  the  interaction  class  structure  [8].  An  interaction  is  an  explicit 
action  taken  by  an  object  that  can  optionally  be  directed  toward  other  objects.  In  this 
case,  Weapon  Detonate  is  the  base  interaction  class,  and  Weapon  Detonate  at  Air  Target 
and  Weapon  Detonate  at  Ground  Target  arc  both  inherited  from  Weapon  Detonate.  This 
table  also  lists  the  initiating  and  receiving  object  and  the  affected  attributes  for  each  object. 


Object  Interaction  Table 

Interaction  Struct lire 

Initiating  Object 

Receiving  Object/ Area 

Interaction 

Parameter* 

InaV 

Sens*/ 
React 

Class 

Affactad 

Attributes 

Class 

Affected 
Attributes 

<inter  action  > 

[<  interaction^ 

<class> 
[.<clasa>r 

[<attnbute>] 
(.<attnbute>r 
[(<comment>))* 

[<class>] 
[,<dass>p 

(<attnbu1e>i 
[,<attnbute>r 
[{<romment>)]* 

[<parameter>] 
[,<pansmeter>J* 

<isr> 

[<  interaction.*] 

<class> 

[.<class>]* 

[<annbute>] 

[.<artnbute>r 
[{<comment>}]* 

[<daas>] 

[.<class>r 

[<attnbute>] 
|.<attnbute>r 
((<comment>)]* 

[<parameter>] 
(.<paramater>r 

<isr> 

-. 

-. 

- 

- 

- 

.. 

- 

<interaction> 

[<  inter  act  ion  >] 

<class> 

[,<class>r 

(<aflnbute>) 
[,<attnbuts>]" 
((<comment>)]' 

[<daas>] 
[,<dasx>f 

[<attnbute>] 
[.<attnbute>J* 

[(<comment>)J* 

[<parameter>i 

[,<parameter>]* 

<or> 

- 

■- 

- 

- 

_ 

- 

- 

Weapon 

Detonate 

Weapon  Detonate 
at  Ajr  Target 

Weapon 

Velocity. 

Acceleration. 

Weight. 

Air  Vehicle 

Velocity, 

Acceleration, 

Weight, 

Weapon  Location 

Warhead. 
Weapon  Attitude. 

m 

Weapon  Detonate 
at  Ground  Target 

Table  2:  Object  Interaction  Table 

The  last  column  in  the  table  shows  the  three  basic  categories  of  interaction: 

•  Initiates  (I):  indicates  that  a  federate  is  currently  capable  of  initiating  and  sending 
interactions  of  the  type  specified  in  that  row. 

•  Senses  (S):  indicates  that  a  federate  is  currently  capable  of  subscribing  to  the  interaction 
and  utilizing  the  interaction  information,  without  necessarily  being  able  to  effect  the 
appropriate  changes  to  affected  objects. 

•  Reacts  (R):  indicates  that  federate  is  currently  capable  of  subscribing  and  properly 
reacting  to  the  interactions  of  the  type  specified  by  effecting  the  appropriate  changes  to 
any  owned  attributes  of  the  affected  objects. 

In  a  FOM  definition,  all  of  the  above  are  valid  entries.    There  would  not  be  a  listing  if 
there  was  not  a  federate  responsible  for  the  interaction. 
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a.  Attribute/Parameter  Table 

Finally,  the  Attribute/Parameter  Table  [8]  defines  characteristics  pertinent 
to  each  Class/Interaction  described  in  Table  1  and  Table  2.  Interactions  are  published  by 
and  subscribed  to  by  federates  depending  on  the  structure  of  the  federation.  Table  3  is  the 
Attribute/Parameter  Table  for  a  Tank  Object  and  the  Weapon  Detonate  Interaction.  For 
each  Object/Interaction  the 


Ob  fact 
Interact  Ion 

Attribute 
Par  ■meter 

Data 
Type 

Cardinality 

Unlta 

Raaolution 

Accuracy 

Accuracy 
CondHlon 

Update 

Type 

Updata 

Condition 

T/A 

U/R 

<dass>  1 

<lnt  erect  ion> 

<attnbute>l 
<parameter> 

<datatype> 

[<size>] 

<units> 

<  resolutory 

<acouracy> 

<cond<KXi> 

<type> 

<rate>  I 
<condrbon> 

<ta> 

<ur> 

<aftnbute>l 
<parameter> 

<  datatype  > 

|<sae>] 

<unrts> 

<resolutcn> 

<acouracy> 

<cond«ion> 

<type> 

<oondrt)on> 

<la> 

<ur> 

[<sce>! 

<ciass>  1 
<lntefact)on> 

<attnbute>l 
<parameter> 

<datatype> 

(<scze>) 

<unrts> 

<resolutcn> 

<accuracy> 

<condilKyi> 

<type> 

<condrUon> 

<1a> 

<ur> 

<attrtbuie>l 
<perameter> 

<dalatype> 

(<see>l 

<unrts> 

<resolution> 

<accuracy> 

<coodrtjon> 

<type> 

<rate>  I 
<condrbon> 

<ta> 

<ur> 

[<sce>] 

<cbss  >  1 
<  Interact  ion> 

<attnbute>> 
<parameter> 

<datatype> 

[<SE6>] 

<unrts> 

<resoluliort> 

<aocuracy> 

<condrtion> 

<Type> 

<TBte>  t 
<condrbon> 

<ta> 

<ur> 

(<stze>] 

- 

Tank 

Area 

Float 

1 

m2 

0.1  n\2 

perfect 

always 

coodrtonal 

seen  events 

TA 

UR 

Velocity 

Double 

1 

m/sec 

1  m/sec 

.01  nVsoc 

none 

perKxftc 

10  Hz 

TA 

UR 

Stale 

TanK_Type 

i 

n/a 

rVa 

n/a 

rVa 

cortdrtional 

seen  events 

TA 

UR 

Position 

Rectng_Type 

1 

n/a 

rVa 

n/a 

rVa 

penodic 

10  Hz 

TA 

UR 

Weapon 

Detonate 

Warhead 

Wh.Type 

1 

n/a 

n/a 

n/a 

n/a 

rVa 

rVa 

rVa 

n/a 

Table  3:  Attribute/Parameter  Table 

attributes  or  parameters  are  defined  and  characterized  by  multiple  descriptors  like  data 
type  and  units  of  measure.  The  second  to  last  column,  Transferable/ Acceptable  refers  to  a 
federate' s  ability  to  transfer  or  accept  the  responsibility  to  update  the  specified  attributes 
for  a  particular  entity.  For  a  FOM,  the  only  acceptable  entries  are  (TA)  for 
Transferable/ Acceptable  or  (N)  for  Not  Transferable/ Acceptable.  The  last  column  refers 
to  a  federate's  capability  to  update  (U)  and  reflect  (R)  attributes  or  parameters.  In  a 
FOM,  all  attributes  or  parameters  should  be  marked  both  updatable  and  reflectable. 
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2.  Simulation  Object  Model 

A  FOM  is  the  union  of  all  SOMs  used  to  define  the  federation.  The  SOM  uses  the 
same  templates  as  the  FOM.  The  Object  Class  Table  in  Table  1  describes  the  object 
classes  represented  in  the  federation.  A  SOM  object  class  structure  table  would  designate 
which  classes  the  federate  publishes  (P)  and  which  it  has  the  capability  to  subscribe  (S). 
For  example,  the  F-16  federate  might  publish  the  F-16  object  and  subscribe  to  air  vehicle 
so  it  would  know  the  location  and  speed  of  all  other  aircraft  in  the  federation.  Similarly, 
the  Object  Interaction  table  would  differ  in  the  last  column  because  the  federate  must 
identify  what  interactions  it  has  the  capability  to  process.  The  F-16  federate  might  put  a 
(R)  in  the  last  column  of  Table  2  to  indicate  that  it  reacts  to  a  Weapon  Detonation  at  an 
Air  Target.  Additionally,  a  (I)  might  go  in  the  last  column  for  Weapon  Detonate  at 
Ground  Target  to  show  that  the  F-16  federate  initiates  the  interaction  to  fire  weapons  at  a 
ground  target.  Finally,  the  last  two  columns  in  the  Attribute/Parameter  Table  would  be 
modified  to  show  what  capabilities  the  federate  has  in  regards  to  its  ability  to  transfer  and 
accept  attributes  or  update  and  reflect  attributes. 

3.  FOM/SOM  Lexicon 

To  achieve  interoperability  between  simulations,  all  data  required  by  the  federation 
must  be  fully  explained.  It  is  not  enough  to  merely  specify  the  classes  of  data  required  by 
the  templates  above.  The  semantics  of  this  data  must  also  be  explained.  The  FOM/SOM 
Lexicon  provides  a  means  for  federations  to  document  the  definitions  of  all  terms  utilized 
during  construction  of  FOMs,  and  for  individual  federates  to  document  the  definitions  of 
all  terms  provided  in  their  SOMs. 

C.         INTERFACE  SPECIFICATION 

The  IF  Spec  [91  describes  the  runtime  services  provided  to  the  federates  by  the 
RTI,  and  from  the  federates  to  the  RTI.  There  are  six  classes  of  service.  Each  defines  a 
specific  set  of  functions  that  pertain  to  a  particular  type  of  transaction  that  must  be 
accomplished  to  properly  manage  the  federation.  There  are  two  locations  where  the 
function  definitions  reside:  the  RTI  ambassador  and  the  federate  ambassador.  The  RTI 
ambassador  is  the  software  component  provided  by  HLA  and  contains  all  the  functionality 
required  to  accomplish  communication  to  the  network.  The  federate  ambassador  is  the 
RTFs  interface  to  the  federate.  To  pass  data  to  the  federate,  the  RTI  ambassador  makes 
function  calls  to  a  user  defined  federate  ambassador.  The  RTI  ambassador  is  the  same  for 
all  federates  but  the  federate  ambassador  is  different  for  each  federate.   A  full  explanation 
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of  each  function  can  be  found  in  the  HLA  IF  Spec.  The  following  discussion  deals  mainly 
with  the  purpose  of  each  management  service. 

1.  Federation  Management 

Federation  management  services  offer  the  basic  functions  required  to  initiate  the 
federation,  add  federates  and  delete  federates  as  the  federation  finishes  execution.  These 
services  include  Create,  Join,  Pause/Resume,  Resign  and  Destroy  federation. 

2.  Declaration  Management 

Declaration  management  defines  the  services  required  to  support  efficient 
management  of  data  exchange.  It  does  this  by  providing  the  services  that  allow  federate' s 
to  identify  to  the  RTI  ambassador  the  object  and  interaction  classes  they  will  publish  and 
subscribe.  This  service  includes  Publish,  Subscribe,  and  Control  actions  on  specific  object 
classes  and  interactions. 

3.  Object  Management 

Object  management  services  refer  to  all  the  functions  required  to  manage  the 
update  of  object  attributes  during  federation  execution.  The  services  include  Request 
Object  ID  numbers,  Update  object  attributes,  Sending  Interactions,  Receiving  object 
updates,  Receiving  interactions,  Deleting  objects  and  Changing  transportation 
characteristics. 

4.  Ownership  Management 

Ownership  management  refers  to  the  dynamic  transfer  of  ownership  of  object 
attributes  during  federation  execution.  The  services  include  Request  attribute  ownership, 
Divest  Attribute  ownership  and  Release  attribute  ownership. 

5.  Time  Management 

Time  management  services  support  the  synchronization  of  runtime  simulation  data 
exchange.  The  current  HLA  time  management  service  provides  support  for  time-step  and 
event-driven  simulation  systems  but  support  for  platform  level  real-time  simulations  is 
limited  to  wall  clock  time. 
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6.  Data  Distribution  Management 

Data  distribution  management  supports  the  efficient  routing  of  data  among 
federates  during  the  course  of  a  federation  execution.  This  service  allows  federates  to 
identify  regions  of  interest  and  limit  attribute  to  entities  that  fall  into  those  regions. 

D.         HLA  RULES 

There  are  ten  basic  rules  that  define  the  responsibilities  and  relationships  between 
HLA  federates  and  the  federation.  There  are  ten  rules:  five  rules  apply  to  federations  and 
five  rules  apply  to  federates  [10]. 

1.  Federation  Rules 

•  Rule  1:  Federations  shall  have  an  HLA  FOM,  documented  in  accordance  with  the 
HLAOMT. 

•  Rule  2:  In  a  federation,  all  object  representation  shall  be  in  the  federates,  not  in  the 
runtime  infrastructure.  This  means  that  the  RTI  cannot  be  used  to  track  entity  state.  All 
entity  representations  are  defined  by  the  federate  and  communicated  to  other  federates  via 
the  RTI. 

•  Rule  3:  During  a  federation  execution,  all  exchanges  of  FOM  data  among  federates 
shall  occur  via  the  RTI. 

•  Rule  4:  During  a  federation  execution,  federates  shall  interact  with  the  RTI  in 
accordance  with  the  HLA  IF  Spec.  The  only  way  to  interface  with  the  RTI  is  through  the 
RTI  ambassador  and  the  services  provided  in  that  class 

•  Rule  5:  During  a  federation  execution,  an  attribute  of  an  instance  of  an  object  shall 
be  owned  by  only  one  federate  at  any  given  time.  No  attribute  can  be  published  by  more 
than  one  federate  at  a  time. 


2.  Federate  Rules 

•  Rule  6:  Federates  shall  have  an  HLA  SOM  documented  in  accordance  with  the 
HLA  OMT.  Each  simulation  must  describe  the  functionality  it  will  provide  to  the 
federation.  The  federation  is  not  required  to  use  all  the  functionality  supplied  by  the 
federate. 

•  Rule  7:  Federates  shall  be  able  to  update  and/or  reflect  any  attributes  of  objects  in 
their  SOM  and  send  and /or  receive  SOM  object  interactions  externally,  as  specified  in  their 
SOM. 

•  Rule  8:  Federates  shall  be  able  to  transfer  and/or  accept  ownership  of  attributes 
dynamically  during  a  federation  execution,  as  specified  in  their  SOM. 
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•  Rule  9:  Federates  shall  be  able  to  vary  the  conditions  (e.g.,  thresholds)  under  which 
they  provide  updates  of  attributes  of  objects,  as  specified  in  their  SOM. 

•  Rule  10:  Federates  shall  be  able  to  manage  local  time  in  a  way  that  will  allow  them 
to  coordinate  data  exchange  with  other  members  of  a  federation.  Non-time  managed 
federates  manage  time  internally  in  their  own  way,  but  time  managed  federates  must  manage 
time  in  such  a  way  so  it  appears  there  is  only  one  clock. 


E.         HLA  CONCLUSION 

The  HLA  architecture  is  designed  to  improve  the  method  of  simulation  interaction 
by  making  certain  types  of  simulation  systems  reusable  among  disparate  simulation 
applications.  It  accomplishes  this  goal  by  providing  a  standard  method  of  communicating 
simulation  capabilities  (SOM)  and  a  standard  method  of  defining  how  those  simulations 
will  communicate  on  the  network  (FOM).  The  RTI  provides  the  communications  link  to 
manage  the  operation  of  a  federation  using  the  IF  Spec.  The  HLA  rules  link  it  all  together 
by  providing  guidelines  that  ensure  designers  will  use  all  the  components  is  such  a  way  as 
to  accomplish  the  goal  of  reusable  inter-operating  simulations 
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IV.      IMPLEMENTATION 

A.         INTRODUCTION 

The  goal  is  to  provide  a  dynamic,  flexible,  and  consistent  environment  for  three- 
dimensional  networked  virtual  environments.  Consistency  is  accomplished  by  ensuring  all 
modules  are  available  locally  or  via  the  network  from  a  centralized  location.  As  the 
simulation  executes,  users  decide  which  terrain  module  to  use  and  which  simulation 
entities  will  populate  the  environment.  Bamboo  provides  the  ability  to  dynamically  load 
and  unload  modules.  The  ability  to  add  a  module  provides  dynamic  extensibility.  It  is  the 
ability  to  unload  modules  that  makes  the  system  flexible.  Flexibility  requires  that  the 
implementers  can  change  the  virtual  environment  on  the  fly  without  restarting. 

To  this  end,  the  implementation  has  three  major  components:  the  HLA 
administration  module  (amHLAAdmin),  entity  modules,  and  terrain  modules.  The 
amHLAAdmin  module  manages  the  communication  layer  (RTI),  module  loading  and 
unloading,  and  all  participating  entity  objects.  Each  entity  module  represents  the  behavior 
and  polygonal  representation  for  each  entity.  The  terrain  modules  are  the  same  as  the 
entity  modules  but  they  must  be  identified  as  terrain  for  the  amHLAAdmin  module.  These 
modules  make  up  the  core  of  this  implementation.  Each  component  is  described  in  detail 
in  the  following  sections. 

1.  HLA  Administration  Module  (amHLAAdmin) 

The  amHLAAdmin  module  manages  HLA  RTI  communications,  Bamboo  function 
calls,  the  execution  window,  and  entities  in  the  environment.  All  modules  designed  for  the 
implementation  depend  on  the  amHLAAdmin  module.  Therefore,  Bamboo  ensures  it 
loads  before  any  entity  or  terrain  module.  Similarly,  the  amHLAAdmin  module  depends 
on  various  modules  being  loaded  before  it.  Figure  3  shows  the  module  dependency  tree 
for  a  typical  execution.  Notice  that  amEntity  and  amTerrain  depend  on  amHLAAdmin, 
and  that  amHLAAdmin  depends  on  Visual,  Keyboard,  and  amPageModule. 
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Figure  3:  Implementation  Module  Dependency  View 

Since  the  amHLAAdmin  module  must  communicate  with  the  RTI  and 
entity/terrain  modules,  the  API  and  pure  virtual  class  provide  the  interface  to  accomplish 
this  communication.  Essentially,  the  amHLAAdmin  module  instantiates  the  Admin  class 
object.  Through  static  functions,  the  Admin  class  provides  the  API  for  entity/terrain 
modules  to  communicate  with  the  RTI  and  manage  instances  of  their  entities.  Each 
entity/terrain  class  must  inherit  from  amObject.  This  object  defines  the  interface  for  the 
Admin  object  to  communicate  with  entity/terrain  modules. 

Figure  4  shows  the  object  model  used  by  this  implementation.  This  figure 
illustrates  the  relationship  between  the  Admin  object  and  the  entity  modules.  It  also  shows 
how  the  pure  virtual  class  amObject  is  used  to  ensure  that  each  federate  transmits  and 
receives  all  information  pertinent  to  the  federation.  An  entity  update  coming  from  the 
network  begins  in  the  RTI  ambassador  receive  buffer. 
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Figure  4:  Object  Interface 

Next,  the  RTI  ambassador  calls  the  AdminFederate  Ambassador-::  reflect  Attribute  Values() 
function  in  the  federate  ambassador).  The  federate  ambassador  is  the  RTI  ambassador's 
interface  into  the  federate.  This  function  simply  calls  the  Admin  object  function  to  pass 
the  AttributeHandleValuePair  to  the  appropriate  entity. 


Called  by  the  RTI  Ambassador  to  pass 

the  AttributeHandleValuePairSet  tO  a  Specific  entity 

void  AdminFederateAmbassador : :ref lectAttributeValues 

(  RTI: :ObjectID  theObject, 

const  RTI: :AttributeHandleValuePairSet&  theAttributes, 
RTI : :FederationTime  theTime. 

const  RTI : :UserSuppliedTag  theTag, 

RTI:  :EventRetractionHandle  theHandle  ) 


throw  (RTI: 

RTI: 
RTI: 
RTI: 


Ob j  ec  tNo  tKnown , 
AttributeNotKnown, 
Inval idFedera  tionTime . 
FederatelnternalError) 


Admin:  :receiveUpdate(  theObject,  theAttributes,  theTime,  theTag,  theHandle)  ; 
)//  end  reflectAttributeValues 


objectiD  is  the  ID  number  for  the  specific  entity 
The  usersuppiiedTag  specifies  the  module  name. 
The  other  parameters  are  not  used  in  this  implementation. 


Figure  5:  Federate  Ambassador  Code  Fragment 
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The  federate  ambassador  calls  the  Admin: :receiveUpdate()  function  in  the  Admin 
object  (Figure  6).  This  function  locates  the  entity  object,  an  amObject  type,  in  the  object 
list.  If  the  object  exists,  it  is  updated.  If  it  does  not  exist,  the  Admin  object  checks  to  see 
if  the  module  is  loaded.  If  the  module  is  loaded,  then  another  object  representing  that 
entity  is  instantiated.  If  the  module  is  not  loaded,  it  is  loaded  and  an  object  representing 
the  entity  is  instantiated. 


Called  by  the  Federate  Ambassador  to  pass 

the  AttributeHandleValuePairSet  tO  a  Specific  entity 

managed  by  the  Admin  object 

void  Admin: :receiveUpdate(  RTI :  :ObjectID  theObject, 

const  RTI: : AttributeHandleValuePairSeti  theAttributes, 

RTI : : FederationTime  theTime, 

const  RTI: :UserSuppliedTag  theTag, 

RTI :  :EventRetractionHandle theHandle  ) 


{ 


Locates  amObject  in  list 


amObject*  tmp  =  Admin:  :  f  indSimEntity  (theObject)  , 


//  find  the  correct  object 


Pass  attributes  to  amObject 


if  (tmp) 

tmp-  >receiveUpdates  ( theObject ,  theAttributes ,  theTime ,  theTag )  , 
else  {      //  add  module  if  necessary  or  add  simEntity 

i f  ( Admin :  : moduleLoaded  ( theTag)  )  t //  is  module  loaded 


Add  entity  of  module  already  loaded 


cout  <<  "adding  new  ■  <<  theTag  <<  endl; 

Admin :  :  addSimEnt  i  ty  ( theTag ,  theOb j  ec  t )  ; 
)//  end  if 
else  { 


Load  module  and  add  entity  from  module 


cout  <<  'Loading  Module  ■  <<  theTag  <<  endl; 

Admin: : loadModule (theTag) ; 

Admin:  :addSimEntity( theTag,  theObject)  ; 


)    ) 


Figure  6:  Admin  Object  Code  Fragment 

The  Admin  object  iterates  the  list  of  entities  and  calls  the 
EntityObject::receiveUpdates()  function  of  the  appropriate  entity  (Figure  7).  This 
function  is  defined  in  the  amObject  pure  virtual  class.  This  function  iterates  the 
AttributeHandleValuePair  and  sets  the  appropriate  state  variables  in  the  entity  object. 
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Called  by  the  Admin  object  to  pass 

the  AttributeHandleValuePairSet  to  the  entity 

void  Boid: :receiveUpdates (    RTI : :ObjectID                                             oid, 

const   RTI: :AttributeHandleValuePairSet&                               theAttributes, 
RTI : :FederationTime    theTime.    RTI: :UserSuppliedTag       theTag) 
{ 

RTI :  :AttributeHandle    attrHandle; 
unsigned   long                   valueLength; 

Iterate  theAttributes  and  set  the  values  in  the  entity  object 

for    (    unsigned   int    i    =   0;    i   <    theAttributes .size () ;    i»+    )     ( 
attrHandle   =    theAttributes .getHandle (    i    ); 
if    (    attrHandle   ==  Admin: :getPositionAttrHandle ( )    )( 

npsVec3f   tmp; 

theAttributes. getValuel    i,     (char*)&tmp,    valueLength    ); 

setPosition(tmp) : 
)//end  if 
else    if    (    attrHandle   ==   Admin: :getOrientationAttrHandle( )    )     ( 

npsQuaternion   tmp; 

theAttributes .getvaluet    i,     (char*)&tmp,    valueLength    ); 

setOrientationl tmp) ; 
}//    end  else    if 
else    if    (    attrHandle   ==   Admin: :getVelocityAttrHandle ( )    )    ( 

npsVec3f   tmp; 

theAttributes .getValuel    i,     (char* ) Strap.    valueLength    ); 

setVelocity (tmp) ; 
)        )        ) 

Figure  7:  Entity  Object  Code  Fragment 

The  Admin  object  is  the  portion  of  the  amHLAAdmin  module  that  implements  the 
Admin  API.  This  API  is  fully  described  in  Appendix  A:  Implementation  Tutorial.  Users 
apply  the  Admin  API  to  ensure  their  modules  are  managed  as  part  of  the  HLA  federation 
and  the  entities  they  represent  are  properly  registered  and  updated  by  the  RTI.  Proper  use 
of  the  API  insures  that  the  federation  will  comply  with  HLA  Rules. 

The  amHLAAdmin  module  loads  and  unloads  modules  in  two  ways:  either 
automatically  at  the  request  of  the  system  or  explicitly  at  the  request  of  the  user.  The 
Admin  class  defines  certain  API  functions  that  load  and  unload  modules  at  the  request  of  a 
module  or  the  system.  Finally,  the  amHLAAdmin  module  loads  user  requested  modules 
using  a  separate  module  called  the  amPageModule  on  which  it  depends.  This  module 
loads  automatically  when  the  amHLAAdmin  module  loads.  The  amPageModule  executes 
the  Bamboo  calls  that  load  and  unload  user  requested  modules.  It  installs  two  keyboard 
events  that  the  implementer  uses  to  arbitrarily  load  and  unload  modules. 

The  amHLAAdmin  module  manages  all  of  the  simulation  entities.  Functionality 
related  to  this  task  are  the  HLA  object  management  tasks  like  registering  and  deleting 
objects  and  ensuring  state  updates  transmit  to  the  correct  entity.  The  amObject  class,  that 
all  objects  inherit  from,  allows  the  amHLAAdmin  module  to  iterate  its  list  of  simulation 
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entities  and  update  each  object  based  on  its  ObjectID,  an  identification  number  provided 
by  the  RTI. 

Each  module's  capability  means  nothing  unless  the  executable  is  extended  to 
include  the  new  module.  Figure  8  illustrates  the  execution  tree  used  in  this 
implementation.  The  amHLAAdmin  module  created  the  symbols  in  bold  outline  when  the 
module  loaded.  Al  is  a  callback  attached  to  the  main  callback  handler  created  by  the 
Bamboo  core.  Al  "ticks"  the  RTI  to  provide  CPU  time  to  the  RTI  ambassador  and  the 
federate  ambassador.  This  callback  drives  the  federate  by  processing  all  updates  and 
providing  them  to  the  correct  simulation  entity.  A2  is  a  callback  attached  to  the  draw 
callback  handler  of  the  Visual  module.  This  callback  calls  the  display  function  of  all 
simulation  objects  using  a  call  to  a  virtual  function  defined  in  amObject  that  all  simulation 
entities  must  implement.  Finally  AK  is  the  callback  representing  all  keyboard  events  that 
are  processed  by  the  amHLAAdmin  module. 


HLAAdmin 
Module(A) 


Entity 
Module(B) 


Figure  8:  Execution  Callback  Tree 
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2.  Simulation  Entities  (amEntity/amTerrain) 

As  the  VE  executes,  if  an  entity  is  updated  that  is  not  currently  represented  on  the 
local  machine,  the  RTI  initiates  the  discovery  process.  The  UserSuppliedTag,  a  character 
string  that  is  transmitted  with  each  update  handle  value  pair,  represents  the  module  name. 
The  handle  value  pair  is  the  HLA  method  of  creating  a  byte  array  for  transmission  on  the 
network.  If  this  module  is  already  loaded,  then  another  object  from  this  module  is 
instantiated.  If  the  module  does  not  exist,  then  Bamboo  loads  it  and  instantiates  an  object 
that  represents  the  newly  discovered  entity. 

Each  simulation  entity  is  a  Bamboo  module.  Each  module  has  two  major 
components:  the  object's  polygonal  representation  and  its  general  behavior.  Therefore, 
when  a  module  loads  as  a  result  of  a  remote  object  update,  the  user  collects  all  the 
controls  of  that  module.  Then  Bamboo  plugs  the  module  into  the  local  event  loop  so  local 
processing  can  compute  entity  appearance  and  behavior.  Figure  4  shows  the  entity 
module  loaded  and  inserted  in  the  executable  with  two  sets  of  callbacks.  Bl  is  the  preapp 
callback  that  gives  the  user  the  ability  to  control  the  object  with  keyboard  input.  BK  is  the 
callback  for  all  the  keyboard  inputs  defined  by  the  module. 

Because  this  system  passes  behaviors  along  with  polygonal  representation,  there  is 
an  opportunity  to  reduce  network  traffic  by  reducing  the  details  of  entity  behavior  that 
previous  systems  transmitted  via  the  network.  This  occurs  because  each  entity  computes 
its  behavior  locally  not  from  a  remote  location.  For  instance,  each  entity  provides  collision 
event  behavior  locally  without  the  need  for  multiple  interactions  transmitted  across  the 
network.  Now  the  entity  module  notifies  the  federation  only  that  a  collision  occurred,  not 
resulting  detailed  state  changes.  Each  entity  computes  those  state  changes  locally  as  a 
result  of  the  interaction.  The  result  is  a  series  of  simulation  actors  whose  behaviors  and 
polygonal  representations  load  dynamically  at  runtime.  This  allows  simulation  managers 
to  easily  experiment  with  the  content  of  the  environment  by  adding  and  subtracting 
functionality  at  runtime.  The  tendency  is  to  think  that  this  applies  only  to  the  graphically 
represented  entities  but  it  could  mean  that  data  loggers  or  analysis  modules  dynamically 
load  and  unload  to  collect  and  analyze  simulation  data.  Bamboo  provides  an 
unprecedented  method  of  adding  functionality  to  an  executing  networked  virtual 
environment. 

3.  Graphics  Rendering 

Bamboo's  Visual  module  renders  the  graphical  objects  in  the  scene.  The 
amHLAAdmin  module  and  the  entity  modules  update  the  object's  position  and  orientation. 
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Each  entity  module  registers  callbacks  with  the  Visual  module  to  ensure  accurate 
rendering  of  the  simulation  entity.  These  callbacks  call  the  appropriate  functions  when  the 
system  needs  to  render  the  graphical  representation  of  each  entity.  See  Figure  4  for  the 
callback  tree  representing  this  implementation. 

B.         FEDERATION  OBJECT  MODEL/SIMULATION  OBJECT  MODEL 

This  implementation  has  a  simple  FOM.  Table  4  displays  the  FOM  tables  for  the 
implementation.  The  FOM  and  SOM  are  the  same  for  this  implementation  because  each 
federate  is  based  on  the  amHLAAdmin  Module  common  for  all  federates.  The  FOM 
defines  the  Entity  State  Object  and  its  attributes  that  define  the  state  of  the  object.  The 
Entity  State  Object  defines  the  attributes  that  will  be  communicated  to  the  network.  Do 
not  confuse  this  object  with  the  software  objects  defined  in  the  implementation.  Those 
C++  objects  may  define  more  variables  that  define  their  state  but  are  not  communicated  to 
the  network.  The  FOM  also  defines  a  very  simple  interaction  called  Collision.  Its  only 
parameter  is  the  ObjectID  number  assigned  to  the  entity  that  has  been  collided  with.  The 
purpose  of  this  interaction  is  to  communicate  to  the  federation  the  ObjectID  of  the  entity 
that  was  damaged.  Each  federate  then  updates  the  state  of  that  entity. 


Object  Q«»  Structure  Table 

EntityState  (PS) 


Object  Interaction  Table 


Interaction 
Structure 


Initiating  Object 
Affected 


Receiving  Object 
Affected 


Class 


Attributes 


:  Class 


Attributes 


Interaction 
Parameters 


Sense 
React 


EntityState  None 


EntityState  Damage 


Entity  ID 


Attribute  Parameter  Definition  Table 

ObJactflnteractJo 

Card-: 
Attribute                      Inaltt  j 
Parameter  Datatype       y       Units 

Updeteabl 
TransJarabl           a 
Reao-                    Accuracy  Update     Update              a             Reflectabl 
tutton  Accuracy  Condition     Type     Condition    Acceptable             e 

Position        any                    1 

perfect       always        Periodic                     TA                   UR 

Orientation  lany                   1i 

perfect       always       Periodc I                 TA                  UR 

EntityState 

Veiocity       any                   1: 

perfect       always       Periodic                   TA                 jUR 

Ammunition  any                      1 
Damage        any                    1; 

perfect       always       Periodic                   TA                  UR 
perfect       always        Periodic                    TA                   UR 

Collision 

unsigned  j 
EntrtylD         long                     1 

perfect        always         N/A          N/A              N/A                   N/A 

Table  4:  Implementation  FOM  Tables 
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C.         IMPLEMENTATION  CONCLUSION 

Recall  the  goal  is  a  dynamically  extensible,  flexible,  consistent,  and  specific  NVE. 
Dynamic  extensibility  is  accomplished  by  using  Bamboo  to  load  and  unload  modules.  The 
NVE  is  consistent  because  the  amHLAAdmin  module  ensures  all  entity  and  terrain 
modules  required  by  the  designers  be  loaded  when  required.  Each  module  is  specific 
because  the  programmer  is  only  concerned  with  one  module  representing  a  particular 
entity.  That  programmer  no  longer  has  to  concern  himself  with  the  representations  and 
behaviors  of  the  other  entities  in  the  environment.  Finally,  all  of  this  adds  up  to  flexible 
environment  that  can  be  changed  during  runtime  to  the  state  required  by  the  simulation 
managers. 

The  preceding  sections  provide  the  overview  of  how  the  implementation 
accomplishes  the  goal  of  providing  a  dynamically  extensible,  flexible,  specific  and 
consistent  NVE.  Appendix  A  provides  a  detailed  implementation  tutorial  that  guides  a 
user  through  the  details  required  to  implement  an  amEntity  module.  Appendix  B  provides 
the  code  examples  that  accompany  the  implementation  tutorial.  Together  these  two 
documents  walk  a  user  through  the  correct  use  of  the  HLA  RTI,  Bamboo  and  the 
amHLAAdmin  module. 
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V.       RESULTS  AND  LIMITATIONS 


A. 


PERFORMANCE  RESULTS 


Two  measures  of  performance  were  used  to  judge  the  merits  of  this 
implementation:  frame  rate  per  second  and  average  time  to  clear  the  event  buffer.  Frame 
rate  per  second  describes  how  the  implementation  impacts  the  graphics  subsystem  Falling 
below  ten  frames  per  second  severely  hampers  virtual  environment  realism.  Time  to  clear 
buffers  shows  the  impact  of  increasing  numbers  of  entities  on  the  system's  ability  to 
update  each  one.  Each  measure  was  sampled  with  different  communication  reliability 
parameters,  specific  numbers  of  entities,  and  federates  participating  in  the  environment. 

1.  Test  Description 

The  system  used  to  evaluate  the  implementation  is  a  Windows  NT  4.0  LAN,  with  a 
166  MHz  Pentium  MMX  CPU  and  32  Megabytes  of  RAM.  Each  system  connects  to  the 
100  Mbps  LAN  with  a  3Com  10/100  Mbps  network  interface  card  through  a  100  Mbps 
hub.  The  graphics  subsystem  on  these  systems  is  not  accelerated.  All  graphics  are 
computed  on  the  system  processor.  There  was  a  single  federate  per  system.  Each 
federate  computed  and  transmitted  position,  orientation,  and  velocity  data  every  fifth 
frame. 


Transport  for  Attribute  Updates  and 
Interactions  is  Either  Reliable  or  Best-Effort 


Federate  A 


Federation 
Execution 


Federate  C 


Federate  B 


Fed  Ex  is  the  RT1 1 .0  exploder 
for  all  reliable  comm:  TCP/IP  streams 


Federate  D 


Federate  A 


Federate  B 


Federate  C 


Best-effort  traffic  via  IP  multicast 


Federate  D 


Figure  9:  HLA  Message  Transport  Types 
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There  are  two  communication  reliability  settings  defined  by  the  HLA  IF  Spec: 
FED_RELIABLE  and  RED_BEST_EFFORT.  FED_RELIABLE  uses  the  federation 
execution  to  ensure  that  each  message  of  this  type  is  delivered  to  each  federate  in  the 
federation.  This  adds  a  significant  number  of  messages  to  the  network  since 
acknowledgements  are  required  to  confirm  delivery  of  each  message. 
FED_BEST_EFFORT  reduces  message  traffic  compared  to  FED_RELIABLE  because 
each  federate  transmits  its  messages  to  a  multicast  address  where  every  other  federate 
reads  the  messages.  There  is  no  requirement  for  acknowledgements,  but  there  is  a  small 
chance  that  a  message  may  be  delivered  improperly  or  not  at  all.  Figure  9shows 
graphically  the  differences  between  FED_RELIABLE  and  FED_BEST_EFFORT 
reliability  settings.  FED_RELIABLE  transport  creates  a  bottleneck  because  the  federation 
execution  process  acts  as  a  server  ensuring  that  all  federates  receive  each  update.  The 
FED_RELIABLE  transport  type  only  allowed  two  federates  in  the  federation  before  the 
federation  execution  was  bottlenecked,  so  no  further  measurements  were  taken.  Two 
federates  does  not  make  a  very  interesting  virtual  world. 

2.         Frame  Rate  Results 

Figure  10  shows  the  frame  rate  results  for  a  federate  using  the 
FED_BEST_EFFORT  transport  protocol.  Notice  that  the  frame  falls  as  the  number  of 
entities  in  the  federation  increases.  This  is  to  be  expected.  Each  new  federate  brings  44 
more  polygons  to  the  virtual  world. 
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Figure  10:  Performance  Results 


3. 


RTI  Event  Buffer  Read  Results 


Figure  10  shows  the  time  to  clear  buffer  results.  The  time  to  clear  buffer  is  the 
time  required  to  process  all  events  in  the  RTI  event  queue.  In  this  implementation  all 
events  are  attribute  updates.  This  test  shows  the  average  time  it  took  to  clear  the  event 
buffer.  Recall  that  the  reliable  transport  type  was  only  able  to  accommodate  two  federates 
with  a  total  of  22  entities  in  the  federation,  while  the  best  effort  transport  type 
accommodated  more  than  three  times  that  with  7  federates  and  77  entities.  Notice  that  the 
average  time  to  clear  the  buffer  increases  with  the  number  of  entities  in  the  federation. 
This  could  limit  scalability,  but  recall  the  limited  power  of  the  test  systems  and  that  the 
entity  module  in  the  test  does  not  implement  dead  reckoning.  Dead  reckoning  could 
reduce  the  number  of  entity  updates  thus  improving  the  time  to  clear  the  buffer. 


B. 


LIMITATIONS 


There  are  two  major  limitations  in  this  implementation.  The  RTI  limits  the 
implementation  due  to  its  static  nature.  The  design  of  the  arnHLAAdmin  module  is 
limited  because  it  lacks  a  method  of  extending  the  executable  by  providing  a  separate 
thread  to  handle  entity  updates. 
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1.  HLA/RTI  Generalization 

This  implementation  is  generalized  except  for  the  HLA/RTI  functionality.  The 
RTI  limits  the  functionality  in  two  ways.  First,  the  RTFs  use  of  text  files  and  environment 
variables  limit  the  flexibility  of  this  implementation.  An  API  interface  that  set  the  RTFs 
state  would  significantly  increase  the  flexibility  of  the  system.  Implementation  of  the  HLA 
functionality  requires  that  RTI  be  installed  on  every  machine  it  is  used  on.  It  would  be 
much  more  flexible  if  the  RTI  could  be  instantiated  anytime  and  its  state  set  with  API 
function  calls.  This  would  allow  the  RTI  to  be  part  of  the  amHLAAdmin  module  and 
could  be  loaded  in  one  step  without  having  to  actually  install  the  RTI  so  that  the  static  text 
files  and  environment  variables  are  defined.  Second,  the  FOM  is  predefined  and  parsed  by 
the  RTI  at  runtime.  If  there  was  an  API  interface  to  change  the  FOM  during  runtime,  the 
federation  could  extend  its  capability  without  requiring  that  the  federation  execution  be 
restarted. 

2.  HLA  Memory  Footprint 

Each  federation  has  three  processes  that  must  exist  in  order  for  the  federation  to 
operate:  the  RTI  executive  process,  the  federation  executive,  and  at  least  one  federate. 
The  RTI  executive  process  requires  approximately  2.5  MB  of  RAM  in  order  to  run,  while 
the  federation  executive  requires  2.5  MB.  Each  federate's  memory  requirements  will 
vary,  but  the  local  RTI  component,  or  RTI  ambassador  requires  12  MB.  This  is  a  total  of 
17  MB  required  on  one  system.  This  is  a  significant  amount  of  memory  that  must  be 
considered  when  designing  systems  portable  to  desktop  systems. 

3.  amHLAAdmin  Module  Limitations 

The  amFILAAdmin  module  does  not  provide  a  method  for  extending  the 
executable.  If  this  module  provided  a  set  of  callbacks  similar  to  the  visual  module's  app, 
cull,  draw  system,  the  implementation  could  better  control  the  sending  and  receiving  of 
information  through  the  RTI.  For  example,  a  separate  thread  could  be  started  that 
continuously  "ticks"  the  RTI,  thus  keeping  its  receive  buffers  clear.  Additionally,  a 
generalized  system  that  allows  each  module  to  register  callbacks  on  an  update  loop  would 
provide  a  more  efficient  method  of  updating  entity  state.  These  improvements  were  not 
made  because  the  significance  of  the  processing  time  required  to  update  entity  state  was 
not  discovered  until  the  final  performance  tests  were  run.  Future  improvements  to  the 
system  will  require  a  better  method  of  managing  processor  time  for  the  RTI  to  update 
entity  state. 
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VI.      CONCLUSIONS 


A.         CONCLUSION 


The  implementation  meets  the  requirements  set  out  in  the  introduction  concerning 
the  improvements  NVEs  require.  The  requirements  are  the  virtual  environment  must  be 
dynamically  extensible,  flexible,  specific,  and  consistent.  This  implementation  is 
dynamically  extensible.  Bamboo  does  an  excellent  job  of  providing  this  capability  by 
implementing  the  ability  to  dynamically  extend  the  executable  and  providing  a  system  that 
defines  module  dependency.  The  ability  to  load  and  unload  modules  on  the  command  of 
the  user  or  the  system  at  any  time  during  execution  adds  flexibility  to  the  NVE.  This 
means  simulation  designers  can  rapidly  prototype  simulation  executions  in  real  time  and 
effectively  design  and  implement  the  virtual  environment.  This  demonstration  verifies  that 
simulation  designers  can  be  more  specific.  In  other  words,  programmers  just  need  to 
implement  their  module.  They  no  longer  need  to  represent  the  other  entities  that  will  exist 
in  the  NVE  or  approximate  their  behavior.  An  entity  module  that  can  be  loaded  as  the 
situation  changes  and  unloaded  when  no  longer  needed  represents  these  remote  entities. 
Finally,  this  system  ensures  that  all  simulations  operating  in  the  NVE  are  consistent  with 
each  other.  The  problem  of  different  terrain  models  at  each  simulation  site  is  solved 
because  all  sites  receive  the  terrain  module  from  the  same  location  and  execute  it  in  the 
same  manner.  This  same  logic  applies  to  the  entity  modules. 

B.         FUTURE  WORK 

The  following  lists  future  projects  that  could  improve  real  time  virtual 
environments. 


1.  Network  Bandwidth  and  Latency  of  the  RTL 

It  is  very  difficult  to  quantify  the  effects  the  RTI  has  on  the  network.  We  do  not 
know  the  methods  used  to  keep  the  distributed  local  RTI  components  updated.  What  is 
the  time  management  method  employed  by  the  RTI?  How  are  the  receive  buffers  filled 
and  emptied?  What  is  the  most  efficient  method  of  clearing  the  buffers?  The  results 
indicate  that  more  information  is  required  to  increase  the  numbers  of  entities  modeled  in  a 
real  time  virtual  environment. 
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2.  Methods  for  Reducing  Network  Traffic  Required  to  Maintain 

Consistent  Entity  State. 

This  work  refers  to  ways  to  improve  the  RTI  for  real-time  simulations.  Area  of 
interest  management  is  a  method  of  accomplishing  this  goal.  The  new  version  of  the  RTI, 
version  1.3-3,  has  implemented  its  own  area  of  interest  management  system  call  Data 
Distribution  Management  (DDM).  Future  work  could  entail  implementing  support  for 
DDM  into  this  implementation. 


3.  Improvements  to  the  Current  Implementation 

There  are  several  ways  to  improve  this  implementation.  First,  the  amHLAAdmin 
module  could  implement  a  series  of  callback  handlers  that  accomplish  the  entity  updates 
and  interactions  required  by  the  system.  This  improvement  would  make  the 
implementation  more  general  by  removing  the  requirement  for  the  amObject  pure  virtual 
class  interface.  Next,  multi-thread  the  implementation  to  provide  specific  amounts  of 
processing  time  to  the  RTI  and  visual  module.  Finally,  implement  a  system  that  ensures 
that  locally  computed  objects  are  updated  first.  Currently,  all  entities  are  in  the  same  list. 
Locally  computed  objects  should  have  a  separate  list  so  they  may  be  updated  at  a  greater 
rate. 
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APPENDIX  A:      IMPLEMENTATION  TUTORIAL 

A.  INTRODUCTION 

This  tutorial  describes  how  to  implement  a  module  that  will  operate  using  the 
HLAAdmin  implementation.  It  has  three  sections:  Bamboo  module  implementation,  HLA 
Implementation,  and  Demo.  The  Bamboo  module  implementation  section  describes  how 
to  build  a  module  for  use  with  the  Bamboo  virtual  environment  toolkit.  The  HLA 
implementation  section  outlines  the  HLA  concepts  that  the  user  must  understand  to 
implement  a  module  for  the  HLAAdmin  implementation.  Finally,  the  Demo  section 
describes  how  to  run  the  existing  implementation.  Taking  each  section  in  turn  will  ensure 
the  user  of  an  overall  understanding  of  the  HLAAdmin  implementation. 

The  system  requirements  for  this  implementation  are,  Windows  NT  4.0,  Visual 
C++  5.0,  RTI  1.0-3  and  rktools.  Visual  C++  is  the  compiler  used  in  the  examples  and 
rktools  provides  the  functionality  needed  to  use  makefiles  that  are  very  similar  to  UNDC 
makefiles.  All  the  RTI  functionality  described  in  this  tutorial  is  explained  in  detail  in  the 
RTI  Programmers  Guide,  see  the  bibliography  in  the  main  section  of  the  thesis. 

B.  BAMBOO  MODULE  IMPLEMENTATION 

The  easiest  way  to  grasp  how  to  implement  a  Bamboo  module  is  to  use  one  as  an 
example.  I  will  use  the  amBoid  module,  available  in  the  code  appendix,  as  the  example 
module.  Bamboo  modules  are  made  up  of  a  minimum  of  four  files:  module. h,  module.c, 
amBoid.h,  amBoid.c.  (The  amBoid  files  are  examples;  any  name  can  be  there.)  Each 
module  is  identified  to  the  Bamboo  kernel  by  six  global  functions  defined  in  the  module.c 
file:  getModuleName(),  getModuleVersion(),  getModuleDate(),  getModuleText(), 
initModule()  and  exitModule().  As  a  module  is  loaded,  Bamboo  creates  a  bbModule 
object  that  holds  pointers  to  these  functions. 

When  the  module  is  loaded,  the  bbModule  object  executes  the  initModule() 
function.  The  initModule()  function  does  the  work  required  to  add  the  module  to  the 
executable  and  instantiate  any  object  required  by  the  module.  The  exitModule()  function 
removes  the  structures  used  to  integrate  the  module  into  the  executable  and  deallocates 
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the  memory  associated  with  any  objects  created  for  use  by  the  module  being  deleted. 
Notice  in  the  example  module. c  that  the  definition  for  the  initModule()  function  makes  one 
call  to  the  initamBoid()  function  in  amBoid.c,  and  the  exitModule  function  makes  one  call 
to  the  exitamBoid()  function  in  amBoid.c. 

The  initamBoidO  function  does  the  functions  described  above.  This  function  is  run 
only  once  immediatley  after  the  module  is  loaded  into  memory.  First,  it  instantiates  a  Boid 
object  for  use  by  the  module.  Then  it  calls  the  initKeyboardFunc()  to  add  callbacks  for 
keyboard  events.  This  is  one  way  to  add  the  module  into  the  program  execution.  The 
other  method  is  to  add  callbacks  that  will  include  the  module's  functionality  into  the 
executable.  This  module  is  added  to  the  executable  by  adding  callbacks  to  the  Visual 
module.  The  initVisualModule()  function  adds  a  callback  to  the  preapp  callback  handler. 
The  callback  is  associated  with  the  preAppFunc()  defined  in  amBoid.c.  This  function 
defines  the  keyboard  controls  and  behavior  for  the  Boid  object  created  in  the  loadBoid() 
function.  After  this  function  is  executed,  the  module  executes  as  part  of  the  Bamboo.exe 
executable  until  a  command  to  unload  the  module. 

On  the  command  to  unload  a  module,  the  bbModule  object  calls  the  exitModule() 
function  defined  in  the  module.c  file.  This  function  in  turn  calls  the  exitamBoid()  function. 
The  exitamBoidO  does  the  housekeeping  required  to  remove  from  memory  all  structures 
like  callbacks  or  objects  related  to  the  module.  In  this  case,  the  exitamBoid()  function  first 
removes  the  event  responses  from  the  keyboard.  Notice  that  these  commands  are  in  the 
reverse  order  of  the  commands  that  were  used  to  create  the  keyboard  events.  Next  the 
preapp  callback  is  removed.  Finally,  all  objects  associated  with  this  module  are  deleted 
from  memory. 

The  last  Bamboo  feature  that  will  be  discussed  deals  with  module  dependency. 
Bamboo  extends  the  plug-in  metaphor  by  implementing  a  system  that  allows  modules  to 
depend  on  other  modules  for  execution.  In  this  example,  the  amBoid  module  depends  on 
the  npsVisualModule,  the  bbKeyboardModule  and  the  amHLAAdmin  module.  The 
module.txt  file  defines  these  dependencies.  Bamboo  ensures  that  all  dependent  modules 
are  loaded  first  before  the  module  that  needs  them  is  loaded. 
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This  concludes  the  Bamboo  section.  It  is  not  complicated  to  load  and  unload  a 
Bamboo  module.  The  user  is  required  only  to  define  the  six  functions  in  the  module. c  file. 
Understand  that  Bamboo's  greatest  strength  is  its  convention  that  defines  generalized 
methods  to  load  and  unload  modules  while  providing  a  system  that  ensures  module 
dependencies  are  enforced. 

C.         HLA  IMPLEMENTATION  SECTION 

HLA  is  implemented  mainly  in  the  amHLAAdmin  module.  Entity  modules  just 
make  an  Admin  API  call  to  pass  or  receive  information  to  the  RTI.  There  is  one  exception 
to  this  that  I  will  address  later  in  this  section.  The  Admin  API  wraps  ups  all  RTI 
ambassador  functions.  When  the  amHLAAdmin  module  loads,  it  instantiates  a  single 
object  of  type  Admin.  The  entire  API  is  static  functions  defined  in  the  Admin  class. 

The  Admin  class  uses  the  following  RTI  functionality  (*  is  a  Federate  Ambassador 
function): 

Federation  Management 

CreateFederationExecution 

JoinFederationExecution 

ResignFederationExecution 

DestroyFederationExecution 
Declaration  Management 

PublishObjectclass 

PublishlnteractionClass 

SubscribeObjectClass  Attributes 

SubscribelnteractionClass 
Object  Management 

RequestID 

RegisterObject 

UpdateAttributeValues 

Disco  verObject* 

Reflect  Attribute  Values* 

Sendlnteraction 

Receivelnteraction* 

DeleteObject 

RemoveObject* 
RTI  Services 

Tick 
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The  RTI  has  other  functions  that  do  not  apply  to  this  implementation  like  time 
management  and  ownership  management.  If  this  functionality  is  required,  the  Admin 
object  can  be  extended.  Refer  to  the  Admin.c  file  in  the  code  appendix  for  the  following 
functions.  Notice  the  Admin  class  constructor  is  protected.  There  can  be  only  one 
instance  of  the  Admin  class  active  so  a  singleton  is  implemented  called  getlnstance()  that 
creates  the  object  the  first  time  it  is  called  and  returns  the  pointer  to  the  object  every  time 
it  is  called.  The  Admin  constructor  instantiates  the  RTI  ambassador  (rtiAmb)  and  the 
Federate  ambassador  (fedAmb)  objects.  The  rtiAmb  is  the  predefined  object  that  contains 
all  the  functionality  that  implements  the  IF  Spec.  The  fedAmb  is  a  pure  virtual  class  that 
defines  the  interface  between  the  RTI  and  the  implementation.  Each  rtiAmb  call  results  in 
a  return  value  from  the  RTI  or,  in  the  case  of  updates,  a  call  to  a  fedAmb  function.  Let  us 
discuss  how  the  implementation  uses  each  of  the  above  RTI  services  and  discuss  the  code 
that  implements  the  service. 

1.  Federation  Management 

The  Admin  constructor  shown  in  Admin.c.  makes  calls  to 
Admin:  :createFederationExecution()  and  Admin:  :joinFederation().  The 
createFederationExecution()  function  calls  Admin:  :rtiAmb- 

>createFederationExecution(fedExecName)  and  passes  it  a  char*  that  defines  the  name  of 
the  Federation  execution.  If  the  federation  already  exists,  the  rtiAmb  throws  a  federation 
already  exists  exception.  If  the  federation  is  new,  then  a  fedex  process  is  spawned  by  the 
RTI.  The  Admin:  :rtiAmr»joinFederationExecution(federateName,  fedExecName, 
fedAmb)  passes  it  the  name  of  the  federate,  the  federation  execution  name  and  a  reference 
to  the  fedAmb  object.  The  name  of  the  federate  is  name  mangled  by  the  RTI  so  it  does 
not  have  to  be  unique  and  the  fedExecName  must  be  the  same  as  was  used  in  the 
createFederationExecution()  function.  The  fedAmb  reference  is  a  pointer  to  the  fedAmb 
created  in  the  Admin  constructor.  The  loop  is  used  to  give  to  the  federate  multiple  tries  to 
join  the  federation  because  the  federation  execution  may  require  more  time  to  configure 
itself  before  it  is  able  to  return  the  federate  ID.  The  federatelD  is  a  unique  number 


36 


assigned  by  the  fedex  that  identifies  your  federate.  It  is  not  required  anywhere  but  may  be 
required  by  the  user. 

The  Admin: :resignFederate()  function  handles  the  resign  federate  and  destroy 
federate  management  functions.  This  function  first  calls  Admin: :rtiAmb- 
>resignFederation()  and  passes  an  enumeration  that  defines  the  clean  up  the  user  wants 
done  prior  to  federate  resignation.  The  implementation  uses 
DELETE_OBJECTS_AND_RELEASE_ATTRTBUTES.  This  value  results  in 
removeObject()  calls  to  the  fedAmb  for  all  locally  updated  entities  and  releases  the 
attributes  on  any  objects  that  must  transfer  attribute  ownership  because  the  federate  is 
resigning.  The  final  call  in  this  function  is  to  the  Admin: :rtiAmb->destroyFederation(). 
This  function  destroys  the  federation  if  there  are  no  other  federates  operating,  otherwise 
an  exception  is  thrown  and  the  federation  continues. 

2.  Declaration  Management 

Declaration  Management  identifies  to  the  rtiAmb  all  the  objects/interactions  and 
attributes/parameters  that  the  federate  is  interested  in.  After  the  federate  is  joined,  the 
user  must  get  from  the  rtiAmb  the  enumerated  values  for  the  objects/interactions  and 
attributes/parameters  computed  when  the  FOM  was  parsed.  The  Admin: :Init()  function 
uses  RTI  support  functions  that  use  the  information  from  the  FOM  to  provide  these 
enumerated  values  for  the  different  objects/interactions  and  attributes/parameters.  Notice 
the  Init()  function  uses  specific  functions  that  provide  the  enumerated  values  for  the 
different  Objects  (getObjectClassHandle(char  *))  and  Attributes 

(getAttributeHandle(ObjectTypeEnum,char  *))  that  will  be  used  by  the  federate.  The  char 
*  parameter  must  match  exactly  with  the  strings  used  to  describe  the  Objects  and 
Attributes  in  the  FOM. 

After  the  enumerated  values  are  saved  by  the  user  using  the  Init()  function,  the 
user  calls  the  Admin: :PublishAndSubscribe()  function.  This  function  makes  RTI  calls  that 
tell  the  rtiAmb  which  Objects/Interactions  and  Attributes/Parameters  the  federate  will 
publish  and  subscribe.  The  mechanics  of  this  operation  begin  with  the  user  building  an 
RTI::AtrributeHandleSet.  This  data  structure  holds  the  attribute  enumerations  for  a 
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specific  object.  The  first  part  of  the  PublishAndSubscribe()  function  builds  the 
RTI::AtrributeHandleSet.  First  the  set  is  declared.  Then  space  is  allocated  for  five 
attributes  using  the  create  method  of  the  RTI::HandleSetFactory  object.  Finally,  all 
attributes  that  the  federate  wants  are  added  to  the  set  using  the  add(AttributeHandle) 
method  and  passed  the  enumeration  for  the  specific  attribute  to  be  added.  After  all  the 
attributes  are  added  to  the  HandleSet  the  Admin: :ms_rtiAmb- 
>subscribeObjectClassAttribute(  ClassHandle,  *HandleSetFactory  )  and 
Admin: :ms_rtiAmb->publishObjectClass(ClassHandle,  *HandleSetFactory)  are  called  to 
tell  the  rtiAmb  those  objects  that  will  be  published  and  subscribed.  The  last  functions  are 
for  subscribing  and  publishing  Interactions.  Notice  that  these  functions  do  not  require  a 
HandleSetFactory.  When  a  federate  subscribes  or  publishes  an  interaction,  it  accepts 
responsibility  for  all  the  parameters  of  that  interaction,  hence  there  is  no  need  to  tell  the 
rtiAmb  which  parameters  it  is  responsible  for. 

The  above  functions  accomplish  all  the  tasks  required  to  publish  and  subscribe  to 
objects/interactions  and  attributes/parameters.  These  are  required  tasks  that  all  federates 
must  accomplish  in  order  to  participate  in  the  federation. 

3.         Object  Management 

Object  management  services  provide  the  functionality  to  identify  entities  to  the 
RTI,  discover  them  on  remote  federates,  and  update  their  attributes  during  the  federation 
execution.  The  RTI  requires  that  all  entities  are  associated  with  an  Object  defined  in  the 
FOM.  All  entities  must  possess  a  unique  ID  number  provided  by  the  RTI.  This  number 
identifies  the  entity  on  all  federates  in  the  federation  and  ensures  updates  and  interactions 
are  processed  on  the  correct  entity. 

The  first  task  when  adding  an  entity  to  the  federation  is  getting  its  Objectld  from 
the  rtiAmb  then  registering  that  ID  with  the  rtiAmb.  The  Admin:  :registerObject()  function 
accomplishes  these  tasks.  First  the  Admin::ms_rtiAmb->requestID(RTI::ObjectIDCount, 
RTI:: Objectld,  RTI::ObjectId  )  function  provides  the  ObjectID  numbers.  Then  the 
Admin::ms_rtiAmb->registerObject(  RTI::ClassHandle,  RTI::ObjectId  )  function  registers 
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the  entity  with  the  rtiAmb  and  associates  it  with  a  Object  that  was  previously  published  or 
subcribed. 

After  the  object  is  registered  with  the  rtiAmb,  the  entity  will  be  updated  and  its 
attributes  reflected  on  all  participating  federates.  This  task  requires  that  the  entity  be 
discovered  by  each  federate  in  the  federation.  Discovery  requires  that  the  entity  be 
updated  at  least  once.  On  the  first  update,  the  rtiAmb  calls  the 

Federate  Ambassador:  :discoverObject()  function.  This  function  then  ensures  the  module  is 
loaded  that  represents  this  object.  After  the  module  is  loaded  an  entity  is  instanced  and  its 
state  is  updated  with  the  attributes  passed  by  the  rtiAmb.  Refer  to  the 
AdminFederate Ambassador. c  file  for  the  discoverObject()  function.  After  the  object  is 
discovered,  all  updates  come  to  it  through  the 

FederateAmbassador::reflectAttributeValues()  function.  We  will  look  at  how  the 
attributes  are  updated  first.  Then  we  will  look  at  the  discoverObject()  function  is  detail. 

Entities  are  updated  using  the  rtiAmb->updateAttributeValues()  function.  The 
implementation  calls  this  function  in  the  Admin: :sendEntityUpdate(RTI::ObjectID  , 
RTI::AttributeHandleValuePairSet&  ,  const  RTI::UserSuppliedTag  ).  Each  entity  must 
implement  the  virtual  function  sendUpdates()  defined  in  amObject.  This  function 
produces  a  RTI::HandleValuePairSet  then  calls  the  Admin: :sendEntityUpdates()  function. 
Refer  to  boid.c  in  the  code  appendix  for  listings  of  entity  functions.  Boid::sendUpdates() 
first  creates  a  Handle ValuePairSet  with  the  attributes  in  it  that  it  wants  to  update.  Then  it 
calls  Admin:  :sendEntityUpdate()  and  passes  it  the  Objectld  of  the  entity  to  be  updated,  its 
Handle  ValuePairSet  and  the  UserSuppliedTag  which  identifies  the  module  that  the  entity 
is  modeled  by.  Admin:  :sendEntityUpdates()  then  calls  the  Admin:  :rtiAmr» 
updateAttributeValues(  Objectld,  HandleValuePairSet,  FederationTime, 
UserSuppliedTag( ).  This  command  sends  a  packet  out  on  the  network  containing  the 
data  specified.  When  a  remote  federate  receives  the  data  the  rtiAmb  calls  the 
FederateAmbassador::discoverObject()  function  if  the  Objectld  is  not  known  to  the 
federate  or  the  Federate  Ambassador:  :reflect  Attribute  Values()  function  if  the  entity  already 
exists  in  that  federate. 
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The  AdminFederateAmbassador: :  reflect  Attribute  Values()  function  calls  the 
Admin:  :receiveUpdate()  function.  This  function  searches  the  list  of  entities  and  then  calls 
the  Boid::receiveUpdates()  virtual  function  defined  by  the  amObject  class.  The 
Boid::receiveUpdates()  function  decodes  the  Handle ValuePair  using  the  getValue() 
method  and  updates  the  appropriate  state  variable.  It  then  deletes  the  HandleValuePair. 

If  the  entity  is  not  known,  the  rtiAmb  calls  the  FederateAmbassador 
::discoverObject()  function.  This  function  ensures  the  appropriate  module  is  loaded  then 
calls  Admin:  :addSimEntity()  to  ensure  the  entity  is  added  to  the  list  of  entities  displayed  by 
the  federate.  On  the  next  update,  the  entity's  state  is  updated  using  the  previously 
described  process. 

The  process  for  interactions  is  very  similar.  An  entity  generates  an  interaction  and 
uses  its  Boid::sendInteraction()  function.  This  function  calls  the  Admin: :rtiAmb- 
>sendInteraction()  function.  This  provides  more  flexibility  to  the  federate.  The 
interaction  is  received  on  the  remote  federates  and  the  rtiAmb  calls 
FederateAmbassador:  :receiveInteraction()  function.  This  function  then  calls  the 
Admin:  :receiveInteraction()  function  which  finds  the  affected  entity  and  calls  the 
Boid::receiveInteraction()  function.  In  this  function  the  parameters  changed  by  the 
interaction  are  modified  and  the  ParameterHandleValueSet  is  deleted. 

This  implementation  also  has  the  ability  to  delete  entities  from  the  federation.  This 
is  accomplished  using  the  RTI  functions  deleteObject  and  removeObject.  When  an  entity 
is  identified  for  deletion,  the  entity  is  deleted  locally  then  the  rtiAmb  is  notified  of  the 
deletion  through  the  deleteObject  function.  This  causes  a  network  message  that  results  in 
the  remote  federate  rtiAmbs  calling  the  FederateAmbassador:  :removeObject()  function. 
The  details  follow  for  this  implementation.  First  an  entity  identified  for  deletion  and  its 
geometry  are  deleted  from  the  local  environment.  Then  the  Admin: .-remove AmObject() 
function  is  called.  This  function  removes  the  entity  from  the  object  list  and  calls 
Admin:  :rtiAmb->deleteObject()  which  results  in  a  call  to  the 
FederateAmbassador:  :removeObject()  function.  This  function  then  calls  the 
Admin:  :removeAmObject()  on  the  remote  federate.  This  process  notifies  the  federation  of 
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the  entities  to  be  deleted  and  makes  the  calls  necessary  to  remove  the  entity  from  the 
object  lists  in  all  federates. 

4.  RTI  Services 

The  final  topic  concerns  how  the  rtiAmb  is  allocated  processing  time.  The  RTI  is  a 
single  threaded  application,  so  processing  time  is  allocated  through  the  use  of  the  tick() 
command.  This  command  causes  the  rtiAmb  to  accomplish  tasks  such  as  clearing  buffers 
and  executing  callbacks  based  on  the  status  of  the  federation. 

The  tick()  function  has  two  forms.  The  form  used  in  the  implementation  ticks  the 
rtiAmb  once  for  each  call.  The  other  form  ,  tick(min,max),  will  tick  the  rtiAmb  for  a 
specific  length  of  time.  Both  forms  return  a  boolean  value  indicating  if  there  are  more 
events  in  the  queue.  This  function  must  be  run  periodically  in  order  for  the  federation  to 
operate.  Waiting  too  long  to  tick  can  result  in  overfull  buffers  that  take  an  inordinate 
amount  of  time  to  clear  thus  reducing  the  overall  speed  of  the  federation.  In  this 
implementation  the  rtiAmb  is  ticked  once  per  frame  to  provide  the  most  updated 
information  to  each  federate. 

D.         DEMO  INSTRUCTIONS 

♦  Start  the  RTI  executive. 

♦  Open  two  command  windows. 

♦  In  both  command  windows,  change  directory  to  the  bamboo  directory. 
♦>  Type  bamboo  amHLAAdmin  in  both  windows. 

>  CTRL-E  exits  amHLAAdmin  (  mouse  must  be  in  the  execution  window  ) 

>  The  federation  execution  (fedex)  should  have  started  in  another  window 

>  There  should  be  two  light  green  windows  (  move  the  top  one  to  see  the  other  ) 

♦  Now  add  modules  to  the  federation. 

>  Add  the  Arena  Terrain. 

■  Type  CTRL-L  to  load  module. 

■  Enter  the  module  name  amArena. 

■  Type  CTRL-T  to  promulgate  the  module  to  all  federates. 

♦  Now  populate  the  environment. 
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>  Type     CTRL-L  to  load  module. 

>  Enter  the  module  name  amBoid. 

>  Type    B  to  create  the  Boid. 

■  Control  the  boid  with  the  arrow  keys. 

■  The  A  key  makes  it  go  forward. 

■  The  S  key  makes  it  go  backward. 
♦   Do  the  above  in  both  windows. 

>  Turn  the  boid  that  you  can  the  other  in  both  windows. 

>  Collide  one  boid  with  the  other. 

■  This  produces  an  interaction. 

■  After  10  hits  the  boid  is  destroyed  and  should  disappear. 

■  To  add  another  boid  type  B  again. 
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is    the    text     !r 


aiuHLAAdmin    Files 


Bamboo 1 .Ob 

4 

npsVisualModule 

bbKeyboardModul- 

npsFlyingCameraModule 

uiPageM  i  - .  •- 


/ .  

//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  module . h 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

li  Description:  This  file  defines  the  global  functions  required  by 

/  /  every  dynamical ly- linked  1 ibrory .   How  these  functions  are 

//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

II  automate  some  of  the  work. 

// 

II  September  1996.  Masters  Thesis 


//  EXECUTIVE  SUMMARY 

/ /  Fi le  Name ;  module . c 

// 

//  Author:    CPT  Stewart    Liles.    Naval    Postgraduate  School 

// 

//  Description;  This  file  defines  the  global  functions  required  by 

//  every  dynamically-linked  library.   How  these  functions  are 

//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

II  automate  some  of  the  work. 

// 

//  September  1998.  Masters  Thesis 


•ifndef  module 

•define  module 


FUNCTION  PROTOTYPE  SPECIFICATIONS 


/    INCLUDES  AND  EXTERNS 

include  <stdlib.h>  //  ato 

include  "module . h" 
include  "amHLAAdmin . h" 


•ifdef  cplusplus 

extern  "C 

( 

•endif 

SIM_API 

const  char  -getModuleName I ) 

SIM  API 

float  getModuleVersiont) ; 

SIM.API 

const  char  "getModuleDate  ( ) 

s:k_ap: 

const  char  "getModuleText  ( ] 

s:m_API  bool  inicModuleu  ; 
SIK.API  bool  exitModule() ; 

■ifdef  cplusplus 

); 
•endif 

•endif  li    module 


const  char  'getModuleName [ } 
t 

return  * amHLAAdmin* , 
) 

float  getModuleVersionl) 
( 
return  1.0; 

const  char  'getModuleDate I ] 
( 

return  "1998/08/01  06:05:48"; 
) 

const  char  "getModuleText ( ] 
( 
return  "arnHLAAdmin  Module  —  CNTL-E  to  exit". 


bool  imtModulef) 


imtAdminO  j 
return  1; 


bool  exitModulel J 


exitAdmint ) ; 
return  1; 
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//    EXECUTIVE  SUMMARY 

//  File  Name   anHLAAdmin  .  h 

//  Author   CPT  Stewart  Liles,  Naval  Postgraduate  School 

/  /  Descr lpt ion :  Defines  the  .-nodule  controls  for  the  a  mH  LAAdm  l  n  modu 

// 

ft  September  1998.  Masters  Thesis 


ifndef  _amHLAAdmi 
define  _amHLAAdmi 


INCLUDES  AND  EXTERNS 


nclude  "admin . h* 


FUNCTION  PROTOTYPE  SPECIFICATIONS 


void  mitAdmin  (  )  ; 
void  exitAdminf); 


INLINED  MEMBER  FUNCTIONS 


EXECUTIVE  SUMMARY 
File  Name  amHLAAdmi 
Author   CPT  Stewart 


Naval  Postgradi.  i 


Description  Defines  the  module  controls  for  the  amHLAAdmir.  module 
This  module  manages  the  communication  between  federates  and 
has  data  structures  avilaole  to  facilite  collision  detection 
and  other  tasks  that  require  comparison  with  all  other 


September  1996.  Masters 


INCLUDES  AND  EXTERNS 


nclude 

•Rti  hh- 

nclude 

•amHLAAdmin  h* 

nclude 

-bbKeyboard  h- 

nclude 

* bbEventResponse 

nclude 

•bbCallback  h" 

nclude 

•bbModule  h" 

nclude 

"adjim  h" 

nclude 

•npsWmdow.  h' 

nclude 

"npsV'iewporc  h* 

nclude 

■npsCurj  J- 

nclude 

"npsVisual.h" 

nclude 

•bbMouse  h" 

nclude 

*amOb]ect  h* 

nclude 

■ace/OS. h" 

nclude 

<m«ch.h> 

n;lud- 

<OL/gl  h> 

fdef  SGI 

•inclua 

e  -bbSGIh- 

ndif 

//  Function  Name: 
11  Task  Makes  l 
//  Return  Value: 


the  executable 


id  lnitAdmml  )  ( 
void  mi  tDisplayWmdowl  ]  , 
void  initKeyboardModule [ ) . 
void  createMai.nCallbackHandle 

Admin:  :  get  Instance!  )  .- 


createMamCallbackHandler  t )  ; 
initKeyboardModule () ; 
initDisplayWindow) ) ; 


net  ion  Name :  exitAdmin i 
sk:  deletes  callbacks 
gracefully 


re  the  module 


id  exitAdmint) { 
bbCallback*         callback; 
bbEventResponse*    even t Response , 
bbCal IbackHandler"  callbackHandler. 

Admin: :getMutex ( } ->acquire ( ) . 

//  delete  keyboard  callbacks 

//  exit  key 

eventResponse  =  bbEventResponse : : f indObject ( •amHLAAdminER_Exit" ) . 

callback  =  bbCallback  ::  findOb]ect  (  -amHLAAdmin_Exi  t*  J  ; 

event Response ->removeCallback[ callback l  ; 

delete  callback, 

//  resign  federate 
Admin : : resignFederate ( ] ; 

//  delete  Admin  instance 

Admin*  tmp  =  Admin  :  :  getlnstance  ;  I  ; 

delete  tmp; 

Admin : :getMutex ()->release(). 

exit (01; 


//  

//  Function  Name:  ini tDisplayWindo 
//  Task:  mits  mam  window  for  th 
If  allows  on  window  open  at  tin 

//     federate 

//  Return  Value:  void 


Did  lnitDisplayWindowl) ( 
void  preDrawFunc (bbObject 
npsWindow  "windo 


•object .  bbDat 


npsCamera  "camera , 

npsViewport  'viewport ; 

npsVec3  f  pos  i t  ion , 

bbCallback  "callback; 

bbCal IbackHandler  "callbackHandler. 

//create  the  window  for  the  simulation 

window  =  new  npsWindow(370.  3701. 

wmdow->setName  I  "AdminWindow"  J  ; 

viewport  =  new  npsViewport [0 . Of .  l.Of.  O.Of,  1 . Of } ; 

viewport->setName i "AdminViewport" 1 ; 

//  camera  to  view  the  area 
camera  =  new  npsCamera I) ; 
camera- >set Name) "AdminCamera*  i  , 
camera->setFarClipi200 .Of ) , 
posit ion. set | O.Of.  3.0£.  10. Of)  ; 
camera->setPosition (position ) ; 

camera->setClearColor(0.66f .  l.Of.  0.66f.  I. Of], 
camera->setAspectMode( npsCamera : :CALC_VERT) ; 
viewport->setCamera  (camera)  ,- 

wmdow->addViewport  (viewport }  ; 

II    callback  to  change  position  of  camera  and  update 
callback  =  npsVisual : : drawCallback [ ) ; 

callbackHandler  =  callback->getPreCal IbackHandler ( ] . 
callback  =  new  bbCallback () ; 
callback->setName  r "amHLAAdmin_preDraw" ) , 
callback->setFunc (preDrawFunc) , 
callbackHandler->addCallbackLast  (callback)  .- 


}//initDisplayWindow 


//  Function  Name:  preDrawFunc ( ) 

//  Task:   calls  Admin : :display  to  update  simulati 

//  Return  Value:  void 


id  preDrawFunc ibbObject  'object,  bbData  "data] { 
Admin:  getlnstance ( ) ->dispiay [) ; 
/  end  preDrawFunc 


Function  Name:  createKamCal  IbackHandler  ( ) 

Task;   puts  callback  on  the  bamboo  main  event  loop.   this  is  done 

because  RTI  1.0-3  requires  that  the  RTI  be  ticked  from  the 

same  thread  that  instantiated  it 
Return  Valuer  void 
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id  createMainCallbackHandler  li  ( 
vsid  hlaTickRTI [bbObject  -object.  bbData  "data!. 


bbCallback' 
bbCallbockJHandler 


callback. 
callbackHandle 


callbackHandler  -  bbCal  IbackWand  It  :. 
caliback  -  new  bbCal lback I ) , 
caLlback->5etNamei-rtiTick*] , 

i  *->setFunc(hlaTickRTI>  . 
callbackHandler->addCallbackLa5t (callba 


nCallbackHandl 


-:•  I 


■ 


//  Function  Name   mi  tKeyboardModule 

creates  module  keyboard  callbacks 
//  Return  Value   void 


oid  mitKeyboardModul-    | 

void  exitFuncfbbObject  'object.  bbData  'data); 

void  hlaUpdaceBoid (bbObject  "object.  bbData  'data); 

void  hlaTickRTI (bbObject  -object.  bbData  "data i  , 

void  hlaUpdateObject (bbObject  'object .  bbData  'data! . 

void  hlaUpdateClass tbbObject  'object.  bbData  'data,. 


bbKeyboard 

bb Event Response 

bbCal lback 


•keyboard. 

•evrntRespo 

•callback; 


//  get  the  keyboard  device 

keyboard  =  bbKeyboard :  get  Instance  1 1 . 


.   sec  up  exit  key 
event Response  =  new 

bbEvenCResponse [ bbKeyb 
bbKeyboard:  DOWN_TRANS]  . 

event Response- > set Name!  -amHLAAdminER_Exit  *  )  , 
callback  =   new  bbCallback I ) ; 
eal lback->setName [ *amHLAAdmin_Exit *  J  ; 
callback->setFunc (exitFuncI ; 
eventResponse->addCallbackLast  {callback]  ; 
keyboard->addEventResponse (eventResponse) ; 

}//end  lnitKeyboardModule! ) 


KEY_E  |  bbKeyboard: -CTRL.KASK  | 


/,'  Functii 
Task 


n  Name:  exitFunc 

callbck  function  fo 
nsures  all  callbacks 
Value:  void 


ntrl-e  that 


void  exitFunc (bbObject  'object .  bbData  -data) ( 
int  BiouaeXnWindow 

bbModu 1 e  • modu le . 

if  ImouselnWm  i  - 

module  -  bbModule   f  mdObject  !  -amHLAAdmin*  ;  . 
if  ( 'module! ( 

cout  <<  "arnHLAAdmin  is  not  currently  loaded.  .  ignoring'  <<  endl, 

return. 

)//end  if 

if  I ! bbModule: : unload (modu lei ) ( 

cout  <<    '      Error  unloading  amHLAAdmin  "  <<  endl, 

cout  <<  *   Fatal  Error  -  aborting  executable'*  <<  endl  <<    er.dl. 

exit  (0)  . 

;.'  '  end  if 

- 

)  /  .'  exitFunc  [J 


/  '  

//  Function  Name:  hlaTickRTI 

//  Task:    callback  func  that  makes  the  RTI  calls  that  tick  the  rti 
//       this  provides  the  cpu  time  for  the  rti  to  get  its  work  done 

//  Return  Value:  void 


void  hlaTickRTI IbbObject  'object.  bbData  'data)( 

RTI :  : FederationTime  tmpTime 1 1  0); 
while  (Admin: : g-t Instance! ) ->tickR?I [ j  j  . 
Admin:  ; get  Instance l ) ->update Federation (tmpTime 
)//  end  hlaTickRTI!) 


/  /  Function  Name :  mouselnWmdow 

/ /  Task :    ensures  the  mouse  pointer  is  the  window  that  you 


//  Return  Value:  integer  chat 


interpreted  fo 


t  mouselnWmdow!)  ( 
int  flag  =  0; 

npsWindow  'window; 

npsViewport  'viewport; 

window  =  npsWindow: : f indObjecc ( 'AdminWindoW ) ; 

viewport  =  npsViewport  :  -.  f  indObject  I  "AdmmViewpo 

float  x.y. 

x  =  bbMouse: :getX( ]  \ 


y    -    bbMouse:  getY [ ) j 
bbScreen:  :  normal  neVal  (Lx,  fcy)  ; 


if  (viewport->getWindow( } ->isValInside (x, y) ) { 

flag  =  1; 


return  flag ; 
)//  end  mouselnWindowO 


nd  amHLAAdmi: 


// 


//    EXECUTIVE  SUMMARY 

// 

//  File  Name:  admin. h 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description:  Definition  of  Admin  class 

//    This  file  defines  the  utility  and  external  API  fun 

//     required  to  manage  on  amCompatible  federate 

// 

//  September  1998.  Masters  Thesis 


•include 

"Rti.hh- 

•include 

* AdminFederateAmbassad 

•include 

•npsVec3f .  h' 

•include 

"npsGeometry . h" 

•include 

-bbKeyboard. h' 

•include 

"amObject .h* 

•lfndef 

a  drain 

•define  . 

admin 

•lfndef  SIM_API 
•ifdef  VISUALCPP 

•define  SIM_API  declspec (dllimport ) 

•  else 

•define  SIM_API 
•endif 
•endif 


SIK.API  Admi 


/ /member  variables 
public: 

//  Simulation  Entity  data  memebers 

static  vector<amObject •>     ms_amObjectArray; 

static  unsigned  int   ms_NumberAmObjects ; 

//  Array  of  Objects  used  by  modules 
static  vector<amObject'>  ms_ModuleArray; 
static  unsigned  int   ms_NumberModules; 

//  The  Terrain  Object  pointer 
static  amObjecf  ms_Terrain; 

//  time  management  variables 

static  RTI::Boolean    ms_timeAdvGrant ; 

static  RTI :: FederationTime  ms_grantTime; 
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static  RTI   Fede 


„federateID. 


ft     (lag  cha 
static  RTI: 


lgnals  whether 


me  ct    the  Fede 


m_FedExecName, 


module  locat 
ms.ModuleURL 


//  Static  Member  Data 

it    Federate  Ambassador  P 

static  AdminFederateAmba 


//  RTTI  dat 
static  RTI: 
static  RTI : 
static  RTI 
static  RTI: 

static  RTI • 
static  RTI: 
static  RTI: 
static  RTI: 
static  RTI . 
static  RTI: 


ided  by  the  RTI  during  Initt) 


:Ob:ectClassHandle 
: Attr ibuteHandle 
AttributeHandle 
AttributeHandle 

-ObjectClassHandle 

:AttnbuteHandle 

:AttnbuteHandle 

:AttnbuteHandle 

AttributeHandle 

-AttributeHandle 


ms^AdmmClassHandle; 
ms_ModuleURLAttrHandle, 
ms_HoduleVersionAttr Handle. 
ms_ModuleNameAttrHandle, 

ms_ESClassHandle. 

tns_Posit  lonAttrHandle, 
ms_OrientationAttrHandle, 
ms_VelocityAttrHandle,- 
ms_Ammunit lonAttrHandle , 
ms_DamageAttr Handle, 


RTI: : Inter 


onCla 


_Coll 


ic  RTI : :ParameterHandle 


Names  for  querying  RTTI  valu 


:yIdHandle, 


static 

char' 

cc 

nst 

static 

char* 

cc 

n  s  C 

static 

char* 

CC 

nst 

static 

char- 

c< 

nr. 

static 

char* 

CC 

nst 

static 

char  * 

c<_ 

nst 

static 

char- 

CC 

nst 

static 

char- 

c^ 

n  5  C 

//  construct 

sr 

is 

Admin ( 

//  singleton 

static 

Admin 

•this 

s_ESClassStr  , 
s^PositionStr; 
s_OrientationStr 
s_VelocityStr; 

s_Ammunit  lonStr , 
s_DamageStr  ; 
s_CollisionInter 
s_EntityIdStr. 

e  to  singleton 


cex  used  to  make  Admin  Thread  Sate 

c  ACE_Reeursive_Thread_Mutex  adminMutex 


Z\   10 


membe 
public 

'/  destructo: 

■ 


ensures  update 
id  updateFederat 


f  the  ted-rat 
onfRTI  :F-der 


'■  This  is  the  Admin  API  portio 

■  Singleton  gerrtec 
static  Admin  -get  Instance () . 
' ■  Send  data  to  RTI 
static  void  sendCollisionlntera 


ionT:met  nrwTun-  | 


on (RTI  :FederationTn 
RTI ; ObjectlD  oid 


void  sendEntityUpdate {RTI :: Object  ID  theOb)eet. 
RTI: :AttributeHandleValuepairSetfc  theAtt ributes 
const  RTI :  UserSuppliedTag  theTag] 


Receive  data  from  RTI 
atic  void  receiveUpdate l  FTI . .ObjectID  theObject. 

const  RTI  :  ;ActnbuteHandleValuePairSet&  theAt tributes . 
RTI : : FederationTime  theTime. 

const  RTI :: UserSuppliedTag  theTag. 

RTI  ; EventRetraetionHandle  theHandle  i . 

atic  void  receivelnteractionfRTI : : Interact lonClassHandle 
thelnteraction. 

const  RTI  :  ParaneterKandleValuePairSetS.  theParameters . 
PTI   FederationTime  theTime. 
const  RTI   UserSuppliedTag  theTag. 
RTI: : EventRetraetionHandle  theHandle; . 

Manage  Sim  Entity  Pointers 
atic  void  display! I. 

atic  void  addModuleFunct lonPointer lamObject* ] . 
atic  amObject*      findSimEnt i ty ( RTI : :ObjectID   objectld  ); 
at ic  amObject-      f indSimEnt l ty ( const  char  *  moduleName; ; 
atic  RTI :  :Ob;jectID      registerObject {] : 

atic  amObject*  addSimEnt ity (const  char*  moduleName.  RTI : :ObjectIDj ; 
atic  amObject*  checkEnti tyCol 1  is  ion {amObjecf  that ]  , 
atic  void  removeAmObject (RTI : :ObjectID  old); 

Modu le  Ob] ect  Management 

atic  RTI::  Boolean  moduleLoaded  (const  char*  moduleName)  ,- 
atic  void  loadModule \ const  char"  moduleName) ; 
atic  void  unloadModulelconst  char*  moduleName); 
atic  amObject*  findModule < const  char*  moduleName] ; 
atic  void  removeModule ( const  char*  moduleName); 


RTI  executi 


manage 


Static  RTI::  Boolean  tick.RTI[); 

static  RTI:: Boolean  cickRTI (RTI: :TiekTime  minTick. RTI ; .TickTim 

static  void  advanceTime (RTI : : FederationTime  time), 

static  void  resignFederat' 

static  void  joinFederatio: 

static  void  setTimeManagement ( ) ; 

static  void  createFederationExecution ( ) ; 

static  void      Inic (  ) , 

static  void       PublishAndSubscribe( ) ; 

static  ACE_Recursive_Thread_Mutex*  getMut 


cessor  Methods 

atic  Accessor  Methods 

c  RTI: :ObjectClassHandle       getESClassHandle ( ) 
(  return  ms_ESClassHandle;  J; 

getPositionAttrHandle ( ) 
.PositionAttrHandle;  ) ; 

getOnentationAttrHandle  (  ) 
.OrientationAttrHandle;  )  ,- 

getVelocicyAttrHandlet ) 
VelocityAttrHandle;  ) . 

getAmmunitionAttrHandle ( ) 
AmmunitionAttrHandle;  } ; 

getDamageAttrHandle ( ) 
_DamageAttrHandle;  ) ; 


statu 
statu 
statu 
stati- 
statii 


RTI: : AttributeHandle 
{  return  m 

RTI: :AttributeHandle 
(  return  m 

RTI : .AttributeHandle 

RTI: : AttributeHandle 

(  return  m 
RTI:  :AttnbuteHandle 
(  return 


RTI : : Interact lonClassHandle   getCol lisionlnteractionHandle ( ) 
(return  ms_CollisionInteractionHandle; ) 


RTI: : AttributeHandle 
(  return 


getEntityldHandleO 
_EntityIdHandle,  ) , 


);  //  end  Cla 

•endif 


EXECUTIVE  SUMMARY 

File  Name:  admin. c 

Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

Description:  Method  Definitions  of  Admin  class 

This  file  defines  the  utility  and  external  API  fun 

required  to  manage  an  amCompatible  federate 


September  1998,  Masters  The 


•include  -RTI.hh* 

•include  'admin. h" 

•  include  "  AdmmFederateAmbassador 
•include  'npsCeometry . h* 
•include  'bbKeyboard . h* 
•include  'bbModule.h* 

•  include  *  amObject . h" 
•include  *ace/OS.h* 

•  mclude  *  vector,  h" 


//  Static  Variable  initializations 

//  singleton 

Admin  • Admin :: this_  =  0; 

RTI :  :RTIambassador-    Admm  :  :ms_rtiAmb  =  NULL; 

Admin Federate Ambassador-  Admin : :ms_fedAmb  =  NULL, 

RTI:  :FederateHandle   Admin:  -.m_f  ederatelD  =  0; 

vector<amOb3ect->     Admin: : ms_amOb]ectArray; 

unsigned  int    Admin:  :ms_NumberAmOb;iects  =  0; 

vector<amOb}ect*>     Admin : :ms_ModuleArray , 

unsigned  int     Admin: :ms_NumberModules  =  0; 

amObject*  Admin:  :tns_Terrain  =  NULL; 


RTI: :RTI_FALSE; 
ime(l.O); 


//Ti 

me  Management  flags 

ft: 

: Boolean  Admin: :ms  timeAdvGi 

RTI 

: FederationTime  Admin; :ms_< 

FTI 

:FederationTime   Admin: :m_ 

RTI  : 

:Boolean  Admm:  :tns_Interact 

Flag  =  RTI: :RTI_FALSE; 


//  RTTI  data 
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RT1 
RTI 

RTI 
PTI 

pt: 


RTI 

pt: 


char' 
char' 
char' 


ObjectClaasHandl- 
AttributeHandle 
AttributeHandle 
AttributeHandle 
Af.r  ibuteHandle 
Attr lbuteHandie 


■raet iOnClassHandl* 
imeterHandl* 


m«3  for  querying  RTTI 

const  Adm 

const  Adm 

const  Adn> 

const  Adm 

const  Aden 

const  Adm 


char'  const 
char*  const 

char'  const 

char"  const 

ACE_Recursiv 


Admin: 

Admin: 

.Thread  Mut ex 


1 1 U  II 1 1 1 1  H  1 1 ! I il I II II II I i 

Const ruction /Destruction 
I II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  / 1 1 1 1 1 1 1 


sssHandle 

Admin   Jis.Posit  ionAtt  rHandle  ■  0; 
A  torn   m:-_OrientationACtrHanui'-    0 
Admin   m:;_v-locityAttrHandle  -  0. 

Admin   .Ts_Ammunit  ionAtt  rHandle  =  0  . 
.  liamageAttrHandl-  -  0, 

Admil  Lonlnteract  lonHandl- 

Ent icyldHandl e 

"EntityState-  ; 
ms_Por.it  icnStr  =  -position-, 

inStr  ~    "Orientation". 
m  ■  ■  -  ■   .  ■  ■/■'■'  r    "Velocity"  ; 
ms_AmmunitionStr  =  'Ammunition'; 
eStr  -  'Damage* , 

ms_Col lis  ion  Interact lonStr  =  'Collision 
ms_Ent ityldStr  -  "EntitylD*; 

m.FedExecName  -  *HLA_Admin" . 

ms_ModuleURL  =  'URL  not  defined"; 

Admin  :  adminMutex . 


i  1 1 1 1 1  1 1  !  1 1  I  I II  1 1 1 1  I  1 1 1  t  I 
I  1 1 1 1 1 1 1 1 1 1 1  1 1 1 II  I  1 1 1 1 1  1 1 1 


I '  Function  Name i  get  Instance ( ) 
/'  Task:   singleton  accessor  £u 

i     Return  Value:  Admin* 


Admin"  Admin :  : get  Instance ( )  ( 


if  (!chi 

this_ 


new  Admin ( ) : 


return  this_; 
)//end  getlnstanc 


//  Function  Name:  Adminl) 
//  Task:   constructor 
//  Return  Value   none 


Admin: :Admin()  { 


try  //  rtiAmb 


RTI   PTIambais  >  I 
AdminFederateAmbassador I )  , 


II    try  rtiAmb 
catch  (RTI  :  :ConcurrentAccessAtte:nptedl.  e) 


lAmb  and  fedAmf 


catch  (RTI :; Except lond  el 


"Instantiate  rtiAmb  and  fedAmb"  «  endl; 
be  <«  endl; 


createFed-rat lonExe 
jomFederationl)  ; 


J  //  end  constr 


Task: 

Retur 


on  Name:  -Adminl ) 
destructor 

Value:  none 


Admin :  : -Admin  I ) ( 
amObject*  tmp; 
vector<amObjeet ">;: iterator  ptr; 

getMutex I ) ->acquire I ) , 

//delete  all  elements  of  Object  Array 
ptr  =  ms__amObjeetArray  .begin  I )  ; 
while (ptr  ■ -   ms_amOb3 ectArray. end ( ) ) ( 

tmp  =  (amObject* ) "ptr, 

if (tmp) { 

delete  tmp; 

)//end  if 

ptr*-: 


ms_amObj ectArray . empty  I )  ; 

//delete  ms_ModuleArray 

ptr  =  ms_ModuleArray . begin ( ) , 

whiletptr  •=  ms_ModuleArray . end( )  J  { 

tmp  =  (amObject*  I  *ptr; 

i  f ( tmp )  ( 

delete  tmp; 

)//end  if 


ms_ModuleArray  .  empty  ( )  ,- 
getMutex ( ) ->re lease { ] ; 


//  delete 
if (ms_Ter 


_Terrain 

n)  delete 


//  delete  the  ambassadors 

if (ms_rtiAmb)  delete  ms_rtiAmb; 

if ims_fedAmbl  delete  ms_fedAmb; 


//  Function  Name:  f indSimEntity (  RTI :  rObject ID  objectld 
//  Task;  find  a  simulation  entity  given  its  Object  ID 
//  Return  Value:  amObject" 


amObject"  Admin ::£ indSimEntity I  RTI  :  :0bjectID  objectld  )( 


amObject*  amPtr  =  NULL; 
amObject*  tmp  =  NULL; 

vector<amObject*> : :const_iterator   ptr; 

getMutex [ ) ->acquire( )  ; 

//  iterate  the  vector  ms_amObject Array 
for  (ptr  =  ms_amObjectArray .begin! > ;  ptr 
ptr**)  { 

tmp  =  (amObjecf)  I  "ptr)  ; 

if  (tmp  fcfc  (tmp->getEntityID[ )  ==  objectld)  )  ( 
amPtr  =  tmp; 
break; 
)//end  if 
)//end  for 

getMutex ( ) ->release{ ) ; 

return  amPtr; 
)//  end  f  indSimEntity 


amObj  ectArray . end  [ ) ; 


//  Function  Name:  f indSimEntity {  const  char"  moduleName 
//  Task:  find  a  simulation  entity  given  its  Module's  na 
//  Return  Value:  amObject* 


amObject*  Admin: : f indSimEntity ( 


amObject*  amPtr  =  NULL; 
amObject*  tmp  =  NULL. 


oduleName  ) ( 


vector<amObject*>  :  :  const_iterator    ptr; 

getMutex { ) ->aequire{ 1 ; 

//iterate  the  vector 

for  (ptr  =  ms_am0bj ectArray  .  begin  [  )  ;  ptr  J  =  ms_amObj  ectArray  .  end  I )  ; 
ptr**) ( 

tmp  =  (amObject* ) (*ptr) ; 

ifltmp  fcfc  strcmp  (moduleName,  tmp->getModuleName  ( )  )  ==  0)( 
amPtr  =  tmp; 
break; 
)//end  if 
)//end  for 

getMutex ( ) ->release ( )  , 

return  amPtr; 
}//  end  f indSimEntity 


//  Function  Name:  registerObject { ) 

//  Task:   ask  the  RTI  for  a  unique  Object  ID 

//     register  the  Object  as  and  Entity  State  Object  in  the  RTI 

//  Return  Value:  RTI : :0bjectID 


RTI : : Object  ID  Admin:  : regis terObject ()  ( 

RTI: :ObjectID  old  =  0; 
if  (  Admin: ;ms_rtiAmb  ){ 
getMutex ( ) ->acquire I )  ; 

RTI:  :ObjectIDcount  numObjects (1 )  ; 

//  get  the  ID  from  the  RTI 
try( 

Admin : :ms_rtiAmb->request ID(  numObjects 

) 

catch  (RTI : :Exeeptionfc  e) 

( 

cerr  <<  TequestlD*  <<  endl; 

cerr  «    fce  <<  endl; 


//  register  the  ID  as  an  Entity  State  Class  Object 
try' 

Admin:  :ms_rtiAmb->registerObject (  Admin: :getESClassHandle ( ) ,  oid  ) ; 

} 

catch    (RTI : :Exceptionfc   e) 

( 

cerr  <<  'registerObject"  <<  endl; 

cerr  <<    fce  <<  endl ; 
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getMutex ( ) ->rele 

)  //  end  it 


end  register  ob}e 


Function  Name :  Init I 

Task    requests  the  handle  values  for  the  us 

che  FED  file  from  the  RTI 
Return  Value:  void 


defined  obi 


void  Admin  ;  Init  I   )  ! 

if  I  Admin-  ms_rtiAmb  )( 

//  RTTI  for  Objects 
try  ( 

Admin: .ms_ESClassHandle  =  Admin. 
>gecOb)ectClassHandle (ms_ESClassStr I , 


! 


atch  (RTI:  :  Exceptions.  e)t 

cerr  <<  *getOb]ectClassHandle*  <<  endl, 
cerr  <<  fce  <<  endl , 


try  C 

Admin- :ms_Posi t ionAt trHandle  =  Admi 
>getAttributeHandle  <ms_Position5tr 


ms_ESClassHandlel 


catch  (RTI .  :  Exceptions,  e]  { 

cerr  <<  "getAttr ibuteHandle*  <<  endl ; 
cerr  «   &e  <<    endl; 

) 

try( 

Admin  :  :  ins _0r  i en tatiorAt  trHandle    =    Admin    :  ms_rtiAmb- 
>getAttr ibuteHandle (ms_OrientationStr, 


atch    (RTI: : Exceptions    e)     { 

cerr    <■<    'getAttr  ibuteHandle"    <<    endl ; 
cerr    <<    te   <<    endl  ; 


Admin*  :ms_VelocityAttrHandle    =    Admin :    ms^rtiAmb- 
>getAttr IbuteHandle (ms_VelocityStr , 


catch    [RTI ::  Exception*,    el     { 

cerr    <<    "getAttnbuteHandle"    «    endl ; 
cerr   <<    4e   <<   endl, 


s_ESClassHandle) . 


_£SClassHandle) . 


Admin      ms_Ammunit ionAt trHandle    =    Admin : : ms_r t lAmb- 
>getAttr ibuteHandle (ms_Ammuni t lonStr . 


catch    I  RTI    ;  Exceptions,    e)     [ 

cerr    <<    "getAttributeHandle*    <<    endl. 
cerr    «    be    «    endl; 

) 

try( 

Admin : :ms_DamageAt trHandle  =  Admin   ms_r ~ iAmt>- 
> getAttr ibuteHandle [ms_DamageStr . 


rch  (RTI  .  ;  Except  ions,  e)  ( 
cerr  <<  "getAttributeHandle"  <<  endl, 
cerr  «    be  <<  endl. 


//  RTTI  tor  Interactions 
try{ 

Admin:  ms_Col 1 isionlnteractionHandle  = 
Admin: :ms_rtiAmb- 
>get Interact lonClassHandle |ms_CollisionInteractionStr 
) 
catch  (RTI   Exceptions,  e)  ( 

cerr  <<  'getlnteractionClassHandle*  <<  endl, 
cerr  <<  be  <<  endl. 


Admin   ms.EntityldHandle  = 

Admin  :ms_rtiAmb->getParamecerHandle lms_EntityIdStr . 
ms_CollisionInteractionHandle) ; 
) 
catch  (RTI  -  :  Exceptions,  e]  ( 

cerr  <<  "geCParameterHandle*  <<  endl ■ 
cerr  <<  be  «  endl. 


ms_ESClassHandle;  , 


tr.s_ESClassHandle,  . 


)//  end  if 

)//   end  Init 


//  Function  Name:  PublishAndSubscnb*  :  1 

//  Task,   informs  the  RTi  that  this  federate  will  publish  and  subscribe 

//     Entity  State  Objects  and  Collision  Interactions 

//  Return  Value:  void 


void  Admin: : PublishAndSubscribe ( ) { 
if  (  Admin: :ms_rtiAmb  l( 

// __ 

//  To  actually  subscribe  and  publish  we  need  to  build 


//  an  AttributeHandleSet  that  contains  a  list  of 
//  attribute  type  ids  (AttnbuteHandle) . 


RTI: : AttributeHandleSet  "ESClassAt tributes  , 
try  ( 

ESClassAttributes  =  RTI : :AttributeHandleSetFactory :. create (5 ) ; 
> 
catch  (RTI:  :  Exceptions.  e){ 

cerr  <<  "RTI : : AttributeHandleSetFactory : :create"  <<  endl; 

cerr  <<  be  <<  endl; 
) 
try  ( 

ESClassAttributes->add(ms  Posit lonAttrHandle) ; 
) 
catch  [RTI ::  Exceptions,  e)  { 

cerr  <<  "add"  <<  endl; 

cerr  <<  be  <■<   endl  j 
) 
try  { 

ESClassAt t r ibutes ->add (ms_Orien tat ionAt trHandle] ; 
) 
catch  (RTI  :  :  Exceptions  e)  { 

cerr  <<  "add*  <<    endl, 

cerr  <<  be  <<  endl ; 


try  ( 

ESClassAttnbutes->add(ms_VelocityAttrHandle»  j 
) 
catch  (RTI:  :  Exceptions,  e)  { 

cerr  <<    "add*  <<  endl; 

cerr  <<  be  <<  endl; 


try    { 

ESClassAttributes->add [ms_AmmunitionAc trHandle) ; 
) 
catch    (RTI : :Exceptionb   e)     ( 

cerr    <<    "add"    <<    endl; 

cerr  <<  be  <<  endl; 
) 
try  ( 

ESC lassAttr ibutes ->add (ms_DamageAt trHandle) , 
) 
catch  (RTI ::  Exception*,  e)  ( 

cerr  <<  "add"  <<  endl; 

cerr  <<  be  <<  endl; 
) 


Admin: :ms_rtiAmb->subscribeOb]ectClass At tribute (  ms.ESClassHandle 

•ESClassAttributes  ); 


catch  (RTI ::  Exceptions,  e)  { 

cerr  <<  "subscnbeOb^ectClassAt  tribute"  <<  endl  ,- 


be  <<   endl; 


try  { 

Admin ; : ms_rtiAmb->publ lshOb} ect Class t 
_ESClassHandle. "ESClassAttributes) ; 


atch  (RTI  ::  Exceptions,  e)  { 
cerr  <<  "publishObjectCla 
cerr  <<  be  <<  endl; 


try  ( 

Admin: :ms_rtiAmb- 
subscribelnteractionClass (ms_Coll i 


catch  (RTI -:  Exceptions,  e]  ( 

cerr  <<  "subscribeOb^ectClass At tribute*  <<  endl ; 
cerr  <<    be  <■<   endl ; 


try  { 

Admin: :ms_rtiAmb- >publishInteractionClass ( 
_CollisionInteractionHandle) , 
J 
catch  (RTI ::  Except  ions,  e)  ( 

cerr  <<  "publishlnteractionClass*  <<   endl j 

cerr  <<  be  <<    endl; 


ESClassAttributes->empty {) ; 

delete  ESClassAttributes;    //  Deallocate  the  memory 
)//end  if 


)//end  publish  and  subscribe 


Function  Name:  createFederat 10 

nExecutio 

n() 

Task:   makes  RTI  call  that  ere 

ates  the 

federat 

does  already  exist 

//  Return  Value:  void 

//  

void  Admin ! : createFederationExecution [ ) { 

cout  <<  *create?ederationExecution*  «   endl; 

try{ 

/I 

//  A  successful  createFederationExecution  will 
//  the  fedex  process  to  be  executed  on  this  mac 
f  / ---- 

Admin \ :ms_rt iAmb->createFederationExecuti 
Sleep(2000) ; 


_FedExecName  ) ; 
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catch  (  RTI  .  :  Federat lonExeeutionAlreadyExiatsL  -    i 
cerr  <<  "createFedcrationExecution"  <<  endl; 
err:  <•     fce  <<  endl. 
Sleep(5001 ; 
) 
catch  i  RTI  ::  Exception*,  e  I  ( 

cerr  <<  *createF«  lei  H   r.Execut  ion*  <<  endl; 
cerr  *<  fce  <<  endl . 


kl  -Federat  ionEx<-cut  10 


Publ ishAndSubscr  ibe i | 


}//  end  join  federation 


U 


It  Function  Name    ^•r.Tir'n-Managemen'.  i  j 

i  i  Task  ■   ant  a  the  RTI  "  &  C  ime  management  at  ate 

//     This  federate  is  NOT  time  managed 

/ ■  Return  Value,  void 


Function  Name    joinFedarationO 

Task    makes  RTT  call  that  joins  the  federation  that  has  bee 

:r  sacttd 
Return  Value:  void 


void  Admin :  join Federation ( \ ( 

//  give  join  ten  tries  to  get  joined 
lor  tint  ix  =  0;  ix<10. ix**l  ( 
try  ( 

m_federateID  -  Admin   insert  iAmb->  3  oinFederat  lonExecut  ion  { 

"Sim_Admin" .  m_FedExecName.  Admin: :ms_fedAmb) ; 
break; 
) 
catch  (RTI   Federat  lonExecutionDoesNot  Exist*,  e)  ( 

//  no  reason  to  get  excited  tedex  may  not  be  done 

cerr  <<  "Fed  Ex  does  not  exist  trying  again*  <<  endl; 

SleepllOOO)  ; 

continue, 
) 
catch  (  RTI  ::  Exception*,  e  )  { 

cerr  <<  'Fatal  Error  -  Join  Failed"  <<  endl, 

cerr  <<  fce  <<  end-. 

exit (0) ; 
) 
)//  end  for 

//Sleep  to  ensure  federate  is  joined 

SleepOOOO)  ; 

setTimeManagement I  )  ; 


//  The  Admin  class  needs  to  determine  what  the  RTI  is 

//  going  to  call  its  class  type  and  its  attribute's  types. 


void  Admin   secTimeManagTT  \ 
try  [ 

m5_rtiAmb->setTimeConstramed(  RTI   RTI_FALSE 

ms_rt iAmb->turnRegulat lonof : 
) 
catch  ;  RTI  .  Except  ion*.  «    )( 

cerr  <<  'setTimeManagement'  <<    endl; 

cerr  <<  fce  <*  endl . 
) 
)//end  setTimeManagemer.i 


//  Function  Name-   resignFederate ( ) 

//  Task,   deletes  federate  from  the  fedex  and  destroys  the  federation 

//      if  it  is  the  last  federation  to  resign 

//  Return  Value:  void 


id  Admin .: resignFederate () ( 

cout  «    'Resigning  from  federation"  <<   endl ,- 
try  { 

Adjnin  ms_rtiAmb->resignFederationExecution  ( 

RTI  ■DELETE_OBJECTS_AND_RELEASE_ATTRIBUTES) ; 

J 

catch  {RTI  :  Exception*,  el  ( 

cerr  «  "resignFederationExecution*  <<  endl; 

cerr  «  fce  <<  endl; 


ry    ( 

Admin: :ms_rtiAmb->dest royFederationExecut ion (m_FedExecName) , 


catch    (RTI : : Exceptionfc    ej 


*dest roy Federation Ex e 
fce   «    endl; 


) / /end  resiynFede 


//  Function  Name:  advanceTime (RTI : : FederationTime  ttime) 
//  Task:  asks  RTI  if  it  is  alright  to  advance  time  anoth 
//  Return  Value:  void 


catch (RTI :: Exception  fce) 
( 

cerr  <<  "tick"  «   endl, 


advanceTime (RTI : : FederationTime  tti 


try  ( 

Admin:  :ms_rtiAmb->timeAdvanceRequest ( ttime]  ; 

)//try 

catch  (RTI; : Exception*  e)  { 

cerr  <<  *  t imeAdvanceReques t "  «    endl ; 

cerr  <<  fce  <<  endl; 
)  //catch 


Function  Name:   addModuleFunctionPointer (amObject •  amObj ) 

Task:   Adds  the  Object  associated  with  each  module  to  a  vector  that 

will  be  used  later  to  instance  objects  as  needed 
Return  Value:  void 


)//  end  advanceTi 


//  Function  Name:   tickRTK) 

//  Task:   ticks  the  RTi  providing  proces 

//  Return  Value:  Boolean 


RTI:: Boolean  Admin : : tickRTI (J 

C 

RTI::Boolean  events; 

try  { 

events  =  Admin :  :ms_rtiAmb->tick( )  ; 
) 

catch(RTI :: Exception  fce) 
{ 

cerr  «  "tick"  «  endl; 

cerr  <<  fce  <<  endl; 

return  RTI : : RTI.FALSE; 
> 

return  events ; 


void  Admin : : addModuleFunctionPointer (amObject*  amObj )  { 

vector<amObject*> :: iterator  ptr; 

getMutex ( ) ->acquire( ) ; 

//  looks  for  amObj  already  in  vector 

ptr  =  f ind(ms_ModuleArray .begin  I ) . ms_ModuleArray . end ( ) , amObj I ; 

//  if  amObj  in  vector  do  not  add 
if (ptr  ==  ms_ModuleArray  end! ) ) { 
ms_ModuleArray .push_back [amObj )  ; 

) 

Admin: :ms_NumberKodules-*; 

getMutex ( ) ->release( ) ; 

)  //  end  addModuleFunctionPointer 


//  Function  Name:   findModule (const  char'  name) 

//  Task:   returns  pointer  to  the  object  stored  in  the  object  array  that 

//     corresponds  to  a  particular  module 

//  Return  Value:  amObject* 


amObject*  Admin: : findModule (const  char 


//  Function  Name:  tickRTI (RTI : :TiekTime  minTick.  RTI  :  :TickTime  ma 
//  Task:  same  as  above  except  ticks  RTI  for  a  certain  span  of  ti 
//  Return  Value:  void 


RTI::Boolean  Admin ::  tickRTI (RTI : :TickTime  minTick, RTI : :TickTime  maxTick) 
( 

RTI: -.Boolean  events  =  RTI :  :  RTI_FAXSE; 

try  ( 

events  =  Admin:  :ms_rtiAmb->Eick  (minTick.  maxTick)  ; 


amObject*  tmp  =  NULL; 
amObject*  retObj  =  NULL; 

veetor<amObject"> : :const 

getMutex ( ) ->acquire( ) ; 


terator        ptr 


for    (ptr   =    ms_ModuleArray  .begin  ()  ,-    ptr    !=  ms_ModuleArray .end() ;    ptr**) ( 
tmp    =     (amObject") ("ptr); 

if (tmp   fcfc    strcmp(name, tmp->getModuleNam« ( ) )     ==    0)1 
retObj    =    tmp; 
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break. 

)  ■   'end  it 

|  ■   -nd  addSimEntity 

)l /end  for 

getMutex 1 » •> re  lease | )  , 

[  ines ion  Name    loadModule iconst  char"  name  ! 

return  retOb}, 

//  Task   makes  bamboo  csi:  that  .oadu  tne  name  module 

)//  end  f indModule 

//  Return  Value   void 

void  Admin  :  :  loadModule  iconst  char*  nam**j  ( 

bbModule*  mod. 

/  /  Funct  ion  Nam*    moduleLoaded  (const  char  ■  name  ; 

,'/  Task:   boolean  function  returning  true  if  module  name  is  loaded 

getMi.tex  I )  ->acqvire(  I  , 

■  ■     ;jise  otherwise 

.'/  Return  Value;  Boolean 

mod  =  bbModule.  load (name.  ms_ModuleURL)  . 

gecMutex  )  >releasei I ; 

RTI  .  Boolean  Admin .  moduleLoaded  iconst  char*  nan"*'  I 

end  LoadModule 

RTI- : Boolean  flag  =  RTI -  RTI.FALSE; 

bbModule'  mod  =  bbModule  .-:  f  indOb;iect  (namel  - 

if  (mod)  { 

//  Function  Name    unloadModule (const  char"  name) 

flag  =  RTI : :RTI_TRUE. 

Task    makes  bamboo  call  that  unloads  the  name  module 

).■'/  end  if 

//  Return  Value   vsid 

return  flog. 

]  /  ,'  end  moduleLoaded 

void  Admin: : unloadModule (const  char"  name)( 
bbModule*  mod, 

mod  =  bbModule:  . f mdObject (name  1 • 

//  Function  Name:   addSimEnt i ty ( const  char*  name.  RTI  .ObjectID 

oid] 

//  Task:   adds  simulation  entity  to  the  amObjectArray 

getMutex ( )  ->acquire ( j  , 

ft    Return  Value.  amOb]ect* 

" 

bbModule ;  : unload [modi  , 

amObject*  Admin :  addSimEntity ( const  char'  name.  RTI :  ObjectID  o 

d]  | 

getMutex ( ) -> re lease ( ) , 

amObject ■  mod  =  Admin : : f indModule [name ) ; 

}  //  end  unloadModule 

amObject*  trap  =  NULL, 

if  (mod  fab  rnod->isTerrain  (  )  1  ( 

Admin : :ms_Terra in  =  mod->createObject  (old)  ,- 

) / / end  i f 

//  Function  Name:   updateFederation  [RTI  :  FederationTimefa  n-wTimei 

else  if  (mod) ( 

/ /  Task :   iterates  the  amObjectArray  telling  each  local Object  to  update 

trap  ~    mod->createObject (old) ; 

//     the  federation  with  their  current  state 

vector<amObject  *> :  ; iterator  ptr; 

//  Return  Value:  void 

getMutex < ) ->acquire ( ) , 

void  Admin : : updateFederat ion (RTI : : FederationTimefa  newTime) ( 

ms_amObj ect Array  push_back ! tmp) : 

amObject*  tmp  =  NULL; 

Admin: :  ms__NumberAmObjects-* ; 

getMutex ( ) - >re lease ( ) . 

vector<amObject*> :  iterator    ptr; 

)//end  if 

getMutex  [  )  ->acquire  f  )  . 

return  tmp; 

//  iterate  the  amObject Array 

//  Function  Name:   receiveUpdate [  RTI ; :ObjectID  theObject, 

for  (ptr  =  ms_amObjectArray -begin [ ) ;  ptr  ! =  ms_amObjectArray 

end ( ) ; 

//           const  RTI  :  lAttnbuteHandleValuePairSeti  theAttributes. 

ptr**)  ( 

//          RTI :  rFederationTime                    cheTime. 

tmp  =  (amObject') [•per); 

//          const  RTI : :UserSuppliedTag              theTag, 

if (tmp) [ 

//           RTI:  EventRetractionHandle               theHandle  ) 

if (tmp->localObject {) )  [ 

//  Task:   sends  the  handle  value  pair  to  the  correct  amObject. 

tmp->sendUpdates  InewTime)  ; 

//     if  the  moduel  is  not  loaded  then  the  proper  calls  are  made  to 

)//end  if. 

//     load  the  module  for  the  object  to  be  updated 

)//end  if 
)//end  for 

//  Return  Value:  void 

" 

//  do  same  for  the  terrain 

void  Admin:  : receiveUpdate (  RTI :: Object  ID  theObject, 

if  ims_Terrain) { 

const  RTI : :AttnbuteHandleValuePairSetfa  theAttributes, 

if [ms_Terrain->localObject ( )  )  ( 

RTI : :FederationTime                      theTime. 

getMutex ( ) ->acquire ( ) ; 

const  RTI : :UserSuppliedTag               theTag. 

ms_Terram->sendUpdates  (newTime  j  ; 

RTI : :  EventRetractionHandle               theHandle  )  ( 

getMutex ( ) ->release ( )  ; 
) 

//  find  the  correct  object 

)//end  if 

amObject'  tmp  =  Admin  ;:  f  mdSimEntity  ( theObject )  , 

getMutex ( i -> re lease ( ) ; 

if  (tmp) ( 

getMutex ( 1 ->acquire ( )  ; 

)//end  updateFederation 

tmp->receiveUpdates (theObject , theAttributes, theTime, theTag) . 

getMutex () ->re lease O ; 

II    Function  Name:   display!) 

)//  end  if 

//  Task:   iterates  the  amObjectArray  telling  each  amObject  to  d 

splay 

//     its  geometry  in  the  proper  position  and  orientation 

//  add  module  if  necessay  or  add  simEntity 

ll    Return  Value:  void 

else  ( 

cout  <<  'Object  "  <<  theObject  <<  *  not  found  -  adding"  <<  endl,- 

void  Admin .: display [) { 

//  is  module  loaded 

amObj  ect  *  tmp  =  NULL , 

if  [Admin:  : moduleLoaded (theTag) )  £ 

cout  <<  "adding  new  "  <<  theTag  <<  endl; 

if (ms_Terrain)  { 

Admin: : addSimEntity (theTag. theObject) ; 

ms_Terrain- >di splay ( ) ; 

)//  end  if 

J //end  if 

//if  module  not  loaded 

vector<amObject *>:: iterator  ptr; 

else  ( 

cout  «  "Loading  Module  "  «    theTag  <<  endl ; 

getMutex ( ) ->acquire( ] , 

Admin: : loadModule (theTag] , 

Admin: :addSim£ntity [theTag.  theObject) ; 

ptr  =  Admin : :ms_amOb j ect Array .begin ( ) , 

}//  end  else 

whilelptr  '.=   Admin : :ms_amObjectArray. end  1 ) )( 

tmp  =  (amObject") "per; 

)  /  .'  end  else 

1  f  [  tmp ) 

tmp->display  {  1  .- 

)//end  receiveUpdate 

ptr**; 

l//end  while 

getMutex ( )->release( ) ; 

//  Function  Name;  receivelnteract ion (  RTI : : InteractionClassHandle 

//     thelnteraction. 

)  //  end  display 

//           const  RTI: : ParameterHandleValuePairSetfc  theParameters. 

//           RTI: :FederationTime  theTime. 

//           const  RTI: :UserSuppliedTag  theTag. 

//           RTI  : EventRetractionHandle  theHandle 
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Task    sends  inter act  ion  data  to  proper  simEntity 
Return  Value:  void 


Did  Admin   r«C«iveIntoraction I  RTI   Interact lonClassHandle  thelnte 
const  R7I   ParamefrHflndl'-VaiuepairSetfc  chaParametars, 

Bl  *.tionTime  theTime 
const  RTI   UserSuppl  . 
RTI   EventRetractionHandl*-  cheHa 


_Inte 


nFlag) ( 


RTI : ObjectlD  Old  =  0; 

i(  ■  thelnteraction  ss  ms_Col 1  i  sionlnteract  ionl  I 

RTI :  AttributeHandle  paramHandle; 

unsigned  long         valur>ngth, 

for  (  unsigned  mt  ix  -  0,  ix  <  theParametera. »iz«  I) :  ix--  |( 

paramHandle  =  theParameters.getHandle  i> 

if  <  paramHandle  s:  ms_Ent ityldHandle  )[ 

theParameters  get Value  I  ix.  ichar • i ioid.  valueLength  ); 

)//end  it 
)//end  for 

//  find  the  correct  object 

amOb) ect*  ttnp  =  Admin  :  f  indSimEntity  (  (RTI  :  ;  Object  IDI  Old)  ; 
1 1  I tmp 1  i 

J--  Mut  ex  I  i  ->acquire  i  I  ; 


tmp- 


getMut 

)//end  if 
}//end  if 
else  { 

cout  <<  "Interaction  not  Kn 
)//end  else 
-  I   it    Interact lonFlag 

/  end  receive Inter act  ion 


vein t erac t ion t thelnteraction, theParameters 

- >release ( i , 


chaXnceraccio 


//  Function  Name :   sendCol lis  ion Interact ion (RTI   Fede 
ft  theTime.  RTI : : ObjectID  oid) 

//  Task:   sends  Coll isioninteraction  data  to  federati 

//  Return  Value:  void 


i(RTI : -FederationTime  theTi 
RTI: :Ob)ectID  oid) ( 


RTI : :  ParameterHandleValuePairSet*  params  =  NULL, 

RTI :  . ULong  numparams [ 1 1  . 

params  =  RTI. : ParameterSetFactory : : create (numpar 


params- >add  IgetEntityldHandl"?*;    'char')  old,  s;zeof:RTI::Ob)ectIOn. 

getMutex ( j - >acqu i re |  )  . 

try( 

Admin   ms_rtiAmb->send Inter act  ion  igetCol lis ion Interact ior 
•params . theTime  N 
) 
ca  tch  I  RTI  :  Exception!.  eH 

cerr  <<  fce  <«  endl, 
J 

getMutax I ■  »ral«a  i 
J//  end  sendCollicionlnteraction 


Function  Name.   sendEnt ityUpd^t a ( PTI   ObjaetlD  theObject. 

RTI   AttributeHandleValuePairSet*.  theAttributes. 

const  RTI ■ : UserSuppliedTag  theTag) 
Task    sends  the  handle  value  pair  from  an  entity  Co  I     - 

Return  Value   void 


id  Admin  : sendEnt ityUpdate (RTI ; :0b)ectID  theObject. 

RTI : :Attr ibuteHandleVa luePa IrSetfc  theAttributes, 
const  RTI   UserSuppliedTag  theTag) { 


ms_grantTime. 


RTI :: FederationTime   CheTima  -  m_last 

if  (  Admin: ;ms_rtiAmb  I { 

// 

//  Update  state  of  Boid 

// 

getMutex  1 ) ->acquir* I  )  . 

try 
{ 

Admin:  ms_rt iAmb->updateAttributeValues (  theObject. 
theAttributes,  theTime,  theTag  ); 
//  Must  free  the  memory 
theAttributes -empty  I ) ; 
)//end  try 

catch  I  RTI :: Except ionfc  e  ) 
( 


he 


endl; 


)  //end  catch 

getMutex ( I ->release ( )  ; 

)//end  if 

m_lastTime    =    theTime; 
}//end   sendEnt ityUpdate 


//  

//  Function  Name 

//  Task:   does  h 

//  federation 

//  Return  Value: 


emoveAroObjeet (RTI : :ObjectID 
keeping  required  to  remove 


: r emoveAmObject (RTI : :ObjectID  oid) { 


amObjecf  pBoid  =  NULL; 
unsigned  int  ndx  =  0 ; 


//  check  if 

if  (  Admin: : 


em  to  be  deleted 
_Terrain  UU   Admin 


n  module 

>getEntityID( )  ==  oid  }{ 


>localObject () ) ( 


if (Admin; :ms_Terra 

getMutex ( ) ->acquire () ; 

try( 

Admin: :ms_rtiAmb->deleteOb]ect (  Admin: 
0.0,  NULL  ]  ; 
)//end  try 

catch ( RTI :: Except  ion  fce)< 

cerr  <<  -e  <<  endl  ,- 
> //end  catch 


_Terrain->get Entity ID [ ) . 


getMut 


<  ; :  - 


•I  , 


)//end  if 

Admin \  :ms_Terrain->deleteObject ( ) ; 

Admin  :  :ms_Terram  =  NULL; 


not  a  Terrain 


//    Find  the    instance. 


vector<amObject*> :  iterator        ptr; 
amObj  ect "    tmp    =    NULL; 


getMutex  1  ) ->acqui 


*:  ■ 


for  (ptr  =  ms_arnObjectArray .begin ( ) ;  ptr  ! = 
per**) ( 

tmp  =  (amObjecf)  Cptrl  ; 
if (tmp  *■*■  (tmp->getEntityID( 1  bs  oid) ) ( 
pBoid  =  tmp; 
break; 
)//end  if 
)//end  for 


_amObj ect Array. end [ )  , 


if  {  pBoid  ) C 

Admin  ; ms_NumberAmOb jects- - ; 


//  If  the  instance  is  a  local  object 

//  we  should  delete  it  from  the  RTI  space. 

// 

if    (    Admin: :ms_rtiAmb  w    pBoid->localObject ( )     H 
tryt 

Admin : :ms_rtiAmb->deleteObjeet (    pBo id- >get Entity ID ( ) . 
0.0.    NULL    ) ; 


) 

catch(RTI: :Exception  fce) ( 

cerr  <<  4e  <<  endl ; 
) 

)//  end  if 
else  ( 


e.  thi 


II- 


//We  don"t  need 
J //end  else 
ms_amOb] ectArray . erase (ptr) ; 
pBoid->deleteObject ( ) ; 

J //end  if 

getMutex I ) ->re lease ( )  ; 

)//  end  else 
)//end  removeAmObject 


is  a  remote  object  that  removeObject  was 
do  anything  here 


/ /  Function  Name :   removeModule (const  char*  moduleName) 
/ /  Task :   removes  module  object  form  moduel  array 
//  Return  Value:  void 


t  char*  moduleName) ( 


id  Admin: : removeModule 
amObject*  tmpObject  =  NULL. 
amOb j  ect  *  tmp  =  NULL ; 
unsigned  int  ndx  =  0; 

// - - 

//  Find  the  position  of  this  instance. 

// -- 

vector<amObject*> : : iterator        ptr; 

getMutex ( ) ->acquire ( ) ; 

for    (ptr    =    ms_ModuleArray .begin( ) ;    ptr    \-   ms_ModuleArray . end ( ) ;    ptr**)( 
tmp  =    (amObject")  Cptr)  ; 
if  (tmp    -i.     !strcmp(ttnp->getModuleName  (  )  , moduleName)  ==0)  )  { 

tmpObjeet    =    tmp; 

ms_ModuleAr ray .erase (ptr) ; 

break; 
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)//end  if 
Wend  for 

getMutex ( > ->release  ■  | 

if  I  tmpObject  ) 
( 

Admin: :ins_NumberModules- - ; 

delete  tmpOb^ect. 
}  'endif 
)//end  remove  Module 

/  /  

//  Function  Name.   checkEnc ityCollision lamObject *  that) 
/ /  Task:   iterates  Ob^ectArray  looking  for  collisions  wi 

ent ities 
//  Return  Value:  amObject*  it  collided  wuh 
/  

amObject"  Admin:  . checkEntityCollision lamObject •  that)  ( 

amObject*  tmp  =  NULL; 
amObjecf  retOb]  =  NULL. 

vecCor<amObject *> : : iterator  ptr ; 

ptr  =  Admin  :ms_amObjectArray  begin  I  I  ; 

getMutex ; I  - >acquire ( ]  , 

while i ptr  ! =  Admin :  : ms_amOb]ect Array  end  I'M 
Cmp  =  (amObject •) "ptr; 
if  (tmp  ' =  that i ( 

if ltmp->checkCollisionltnat) ) ( 
retOb]  :  tmp; 
break: 
J//end  if 
)//end  if 
ptr-*; 
J / /end  while 

getMutex [ ) -> re  lease) )  ; 

return  retOb j ; 

)//end  checkentityCoilision 


/ /  Function  Name :   getHutex  I  I 

//  Task:   pointer  to  Admin  class  Mutex 

//  Return  Value:  ACE_Recursive_Thread_M-;te 


//  

//  EXECUTIVE  SUMMARY 

// 

//  File  Name  i  AdmmFederateAjnbassador  h 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

/ /  Description :  Method  Definitions  of  Admin FederateAmbassador  cla 

//  This  file  defines  Federate  ambassador  functions  required  fo 

/ /  proper  execution  in  this  federat ion 

//  September  1996,  Masters  Thesis 


"include    "Rti-hh" 

■1 i ndef    _  AdmmFederateAjnbassador 

•define   _AdminFederateAmbassador 


cla 


AdmmFederateAjnbassador  ■  public  RTI  :  :  Federat eAmbas 


( 
public : 

I  f  1 1 1 1 1 1 !  I  f  1 1 1 1 1 1  f  1 1 

II  Federation  Manage 
1 1 1 II 1 1 1 1 1 1 1 1 1  H 1 1 1 1 


1 1 1 1 


II    supplied  C4 


//  2.6 

virtual  void  init latePause  [ 
const  RTI: :PauseLabel  label) 

throw  ( 

RTI: :FederateAlreadyPaused. 
RTI: :FederateInternalErrori ; 

//  2.9 

virtual  void  initiateResume  [) 

throw  ( 

RTI : :FederateNotPaused. 

RTI: : Federate Internal  Error)  . 


//    2.12 

virtual  void  mitiateFederateSave  ( 

const  RTI:  SaveLabel  label)  //  supplied  C4 
throw  ( 

RTI : :UnableToPerformSave. 

RTI : :FederateInternal Error) . 


virtual  void  mitiateFederateSave 
const  RTI :: SaveLabel       label, 
RTI : : Federat ionTime  theTim 
throw  ( 


//  supplied  C4 
//  supplied  CI 


RTJ 
RTI 

RTI: 


InvalidFederationTime. 

UnableToPerformSave. 

FederatelnternalError) 


//  2.16 

virtual  void  initiateRestore  ( 
const  RTI :: SaveLabel  label)  // 
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throw 
RTI 

RTI 

ft: 


Specif ledSaveLabelDoesNot Ex i 
CouldNotRestore. 
FederatelnternalError! ; 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 
II    Declaration  Management  Services  // 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  1 1 1 1 1 1 1 1 1 1 1 1 1 1 

It    3.5 

virtual  void  startUpdates  ( 

RTI ;  ObjectClassHandle    theClass. 
const  RTI  ■:  AttnbuteHandleSeti.  theAttnbute 
throw  [ 


supplied 
supplied 


ObjectClassNotPublished. 
At tributeNot Published. 

FederatelnternalError) . 

al  void  stopUpdates  [ 

RTI: :Ob;ectClassHandle    theClass.       //  suppli 
St  RTI : :AttributeHandleSett  theAttributes)  //  suppli 
I 

Ob] ectClassNotPubl ished. 
At tributeNot Published, 
FederatelnternalError) . 


//  3.6 

virtual  void  startlnteract ionCeneration  I 

RTI : : InteractionClassHandle  theHandle) 
throw  ( 

RTI : : InteractionClassNotPublished, 
RTI : ; FederatelnternalError) ; 

virtual  void  stopInteractionGenerat ion  ( 
RTI  : InteractionClassHandle  theHandle) 

throw  | 

RTI : : InteractionClassNotPublished. 

RTI : : FederatelnternalError i , 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 // 1 1 1 1 
II  Object  Management  Services  // 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


virtua 

1  void 

discoverObject  ( 

RTI: 

:Ob]eetI0 

theObject . 

//  supplied 

_-: 

pt: 

:Ob]ectClassHandle 

theObjectClass. 

//  supplied 

Cl 

ft: 

: Federat ionTime 

theTime, 

U    supplied 

z; 

const  RTI : 

:  UserSuppl ledTag 

theTag. 

//  supplied 

l 

RTI. 

:  EventRetract lonHa 

idle 

theHandle) 

//  supplied 

c: 

throw  [ 

RTI  : 

:CouldNotDiscover. 

RTI 

. Ob] ectClassNot Known. 

ft: 

: InvalidFederationTime, 

ft: 

: Feder 

atelnternalError} ; 

rt: 
RTI 

kt: 

RTI 


L  void  ref ioctAttributeVaiu- 

RTI   ObjectID  ■  ■'    bj«CC. 

;  FT:   Acer  ibuteHandleValuePairSetfc  theAt tributes. 

RTI   Federat lonTim-  theTime. 

. -rSuppliedTag  theTag, 

FT!   Ev-ntRetractionHandle         thoHo 

Ob jectNot Known, 
AttributeNotKnown. 
InvalidFederat lonTima 
FederatelnternalError) . 


supplied  CI 
supplied  C4 
supplied  CI 
supplied  C4 
supplied  CI 


virtual 
const 


throw 
RTI  : 

pt: 
rt: 

RTI 


vain 


actio 
Interaction:!.-* 
■ ParameterHandleValuePai 

Federat lonTime 
:UaorSuppliedTa3 
Event Retract  lonHandle 


the:nteractio 
Set*  ChfiPai  '>rr<"'  -:  5 
theTime. 
theTag. 
theHandle) 


supplied  CI 
suppl led  C4 
supplied  CI 


nteract lonClassNot Known, 
nteract lonParameterNot Known. 
nvalidFederationTime, 

ederaceln-.ern.ilError1  . 


irtual  void 

RTI 
RTI 
RTI: 
const  RTI : 
RTI: 


removcObj»c:  [ 

ObjectID 

ObjectRemovaLReas 

FederationTime 

UserSuppliedTag 


theObject 
theReason 

theTime. 
theTag. 


EventRetractionHandle  theHandle I 


/,'  supplied  CI 

//  supplied  CI 

/  /  supplied  CI 

//  supplied  C4 

ft  supplied  CI 


throw 
RTI 

pt: 

ft: 


I 

: Object Not Known, 
InvalidFederat lonTime. 
FederatelnternalError) , 


virtual   voi 

RTI  :Obje 
RTI: :Obje 
throw  ( 

RTI 

ft: 
rt: 


veObject  | 

theObject.  //  supplied  CI 
valReason  theReason)  / /  supplied  CI 


ObjectNot Known. 
InvalidFederationTi 
Federate Internal  Err 


It    4.15 

virtual  void  provideAttr ibuteValv 
RTI: :ObjectID 

const  RTI : :AttributeHandleSet4 
throw  ( 

RTI : :ObjectNotKnown. 

RTI: :AttributeNotKnown, 

RTI : :Feder at elnternal Error) . 


/  4.17 

irtual  void  ref lectRetraction  ( 

RTI: : EventRetractionHandle  theHandle) 


eUpdate  ( 
theObject. 
theAttnbutes i 


supplied  CI 
supplied  C4 


throw    | 

RTI  i  :  EventNotKnown. 

i-rat^InternalError)  , 

1 1 1  n  1 1 1  n  1 1 1 ;  1 1 1 1 1 1 1 1 !  i  1 1 1 1 1 1  u  1 1 1 
li  Ownership  Management  Services  ft 
I  {  1 1 1  f  f  H  t  i  1 1 1 1 1 1  1 1 1 1 1 1 1 1 1  i  1 1  i  I  1 1 1 1 

I!     5.2 

virtual  RT:  ;  ;AttnbuteHandleSetfc 

requestAttr Lbuc«OwnershipAs8u»ption  ( 


returned  C6 


RTI 
st  RTI: 
at  PTI 


theObject, 
AttnbuteHandleSetfc  of  f-redAt tributes , 
UserSuppliedTag      theTag 1 


supplied  CI 
supplied  C4 
supplied  C4 


Object Not Known, 

At  tributeAl  ready-Owned. 

FederatelnternalExror) 


virtual  RTI  :  :  AttnbuteHandleSet*. 
requestAttributcOwnershipAssumpr . 

PTI  :ObjectID  theObject. 

const  RTI  :  :AttnbuteHandleSetfc  of  f  eredAttnbutes 
throw  [ 


//  returned  C6 


supplied  CI 
supplied  C4 


Object Not Known, 
AttributeAlreadyOwned. 

FederatelnternalError)  ; 


//  5.3 

virtual  void  ac t ributeOwnershipDivest i tureNot i fication  1 

RTI : :ObjectID  theObject.  //  supplied  CI 

const  RTI  :  :  AttributeHandleSeti  releasedAttnbutes  j  //  supplied  C4 
throw  ( 


: Object Not Known. 
: At tributeNot Known. 

:FederateInternalError) , 


irtual  void  attributeOwnershipAcquisitionNoti fication  ( 

RTI : :ObjectID  theObject,         //  supplied  CI 

const  RTI : :AttributeHandleSett  securedAttributes )  //  supplied  C4 


Object Not Known. 
AttributeNotKnown. 
FederatelnternalError )  ; 


//  5.6 

virtual  RTI: :  AttributeHandleSeti. 

requestAttr ibuteOwnershipRe lease  ( 


returned  C6 


RTI: 
const  RTI ! 
const  RTI : 
throw  ( 


Object  ID  theObject. 

AttributeHandleSetfc  Candida teAt tributes 
UserSuppliedTag      theTag) 


supplied  CI 
supplied  C4 
supplied  C4 


Object Not Known. 
AttributeNotKnown, 

FederatelnternalError) , 


//  S.7 

virtual  void  infonnAttributeOwnership  ( 


RTI 
RTI 
RTI 
throw 
RTI 


: Object ID        theObject. 
:AttributeHandle  theAt tribute . 
: FederateHandle   theOwner) 


supplied  CI 
supplied  CI 
supplied  CI 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ! 
II   Time  Management  Services  // 

n in i  inn i in  ii  i  it  t  ii  in  1 1 1 1 

II    6.10 

virtual  void  timeAdvanceCrant  ( 

RTI: : FederationTime  theTime]  //  supplied  CI 
throw  | 

RTI: : InvalidFederationTime. 

RTI ; ;TimeAdvanceWasNotInProgress. 

RTI:  :  Federat  lonTimeAl  ready-Passed. 

RTI: : FederatelnternalError); 


1 1  HI  1 1 1 1 II 1 1 1 1 II I II II 1 1 II I II 1 1 1 II 
II  Data  Distribution  Management  // 
Ifittftlllltttllllltlt/lttllttttll 

II    7.4 

virtual  void  changeThresholds  ( 
RTI: : Region  theRegion, 
RTI :  ThresholdSetfc  cheThresholds J 


'/  supplied 

•/  returned 


thr 


RTI: :RegionNotKnown. 
RTI:  FederatelnternalError) ; 
//  6:17  PM  8/28/96    f ederateAmbServices -hh 


}; 

•endif 


EXECUTIVE  SUMMARY 

File  Name:  AdminFederateAmbassador . c 

Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

Description:  Method  Definitions  of  AdminFederateAmbassador  class 
This  file  defines  Federate  ambassador  functions  required  for 
proper  execution  in  this  federation 


//  September  1999.  Haste 


•include  "AdminFederaceAmbassador.h" 
•include  'Rti.hh* 
•include  "admin. h" 

1 1 1 1 1 1 1 1 1 1 1 1 1 1  III  1 1 1 1 1 1 II 1 1 1 1 1 1 II II 1 1 1 1 1 1 II I II 1 1 1 1  It  1 1 1 1 II 1 1 1 II 1 1/ III  I 

II  AdminFederateAmbassador  Class 

I I I  It  II 1 1 1 1  It  t  It  1 1  / 1 1 1 1 1 1 1 II I  It  It  1 1 1 1 1 1 1 1 II 1 1 1 1  It  1 1  It  II I  It  I  It  II I II I  It  I 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1  HI  1 1 1 1 1 1 1 1 1 1 1 1 1 1 II  III  I  It  1 1 1 1 1 1 II I II I II I 
II   Construction/Destruction 

1 1 1 1 1 1 1 1 1 1 1  u  / 1 1 1 1  n  1 1  ii  1 1 1 1 1 1 1 1 1 1 1  n  1 1 1 1 1 1 1 1 1 1 1 1 1  it  1 1 1 1 1 1 1 1 1 it  ti 1 1  ti  i 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  / 1 1 1 

II    Federation  Management  Services  // 
II 1 1 1 II I  III  1 1 1 1 1 1 1 1 1 1 1 1 II I II II II I II I 

void  AdminFederateAmbassador: :initiatePau 
throw  (RTI: : FederateAlreadyPaused, 
RTI: : FederatelnternalError 1 
{ 

//  Not  implemented  in  1.0 


id  AdminFederateAmbassador: : mitiateResume ( ) 
throw  (RTI: : FederateNotPaused, 

RTI: FederatelnternalError) 


RTI: :Pause«abel  label  ) 


Not  implemented 


) 


it lateFederateSave ( 


void  AdrainFederateAmbassado 
label  ) 

throw  (RTI : rUnableToPerforraSave. 

RTI : : FederatelnternalError) 
I 

//  Not  implemented  in  10 
•ifdef  TEST_SAVE 

saveFlag  =  RTI : : RTI_TRU£; 

cerr  <<  * initiateFederaceSave  called  with  label 
•end if 
> 


st  RTI: :SaveLabel 
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void  AdminFederateAmbas 
Label. 


iitucefederateSavelcons:  RTI   SaveLabel 
RTI:  FederationTime  theTime) 


throw  [RTI 
RTI 
RTI 


r InvalidFederationTi 
: UnableToPerf ormSave 

Federat -Internal  Err 


//  Not  implemented  in 


void  AdminFederateAmbassador 


nst  RTI : :SaveLabel  label) 


throw  [RTI 
RTI 
RTI 


:  Specif ledSaveLabelDoesNot  Exist  . 

:CouldNotRcstore. 

: Federate Internal Error) 


Not  implemented  in  1  0 


■  ■  'I  111  II  III 

II    Declaration  Management  Services  // 

n  i  ti  1 1 1  in  1 1 1 1  u  i  in  n  t  a  i  u  1 1 1 1  n  1 1 


void   AdminFederateAmbassador 


rtUpdates [RTI • :ObjectClassHandle        theCl 
const    RTI  •  :AttnbuteHandleSeti. 


theAttributes) 
throw    [RTI 
RTI 

PTI 


: Obi ectClassNot Published. 
-AttnbuteNotPublished. 
: Federate In ternalError ) 


( 


) 


•AFA   startUpdat.es-  <<  endlj 


//  Gets  called 


-ly    in    1.0    to 


es   you   publish 


void   AdmmFederateAmbassado 


stopUpdates(RTI: : Ob jectClassHandle      theCla 
const    RTI:  :AttnbuteHandleSets. 
theAttributes) 

throw    (RTI ■ :ObjectClassNotPublished. 
RTI:  .AttnbuteNotPublished. 
RTI ; :FederateInternalError) 
{ 
cerr   <<    "stopUpdates-    <<    endl; 

// - - 

//  Never  gets  called  m  1.0  but  we  will  implement  it  for  good  form. 


id  AdminFederateAmbassador:  : start  Interact lonGenerat i 
(RTI- ; InteractionClassHandle  theClass] 
throw  (RTI.  InteractionClassNotPublished. 
RTI:  FederatelnternalError) 


tlnteractionGenerat i 


end!  ; 


) 


void   AdminFederateAmbassador: : stoplnteract lonG 
FT!       InteractionClassHandle    the 
throw    (RTI       InteractionClassNotPublished. 
RTI      FederatelnternalError) 


i 


stopINteractionGeneracion"  <<  endl 
_InteraetionFUg  -  RTI   RTI.FALSE 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

■'    Object  Management  S<- 


void  AdminFederateAinbassadcr   discoverObject  i  PTI   Obj-ctID 
theObject, 


theObjectClas 
theTime. 


RTI   ObjectClassHandle 

PTI   F"-d-rationTime 


const  RTI :  : UserSuppl ledTag  theTag. 
PTI   Event Re tract lonHandle 


(RTI   CouldNot Discover, 
RTI . :ObjectClassNotKnown. 
RTI .  InvalidFederationTim 
RTI .  FederatelnternalErro 

A  discovered  object  ■  << 


is  this  an  object  type  I  Jtnow  about 
(theObjectClass  ==  Admin  : getESClassHandle ( )  )  ( 

//  is  module  loaded 

if  [Admin  -  moduleLoaded  (theTag)  )  ( 

Admin  :  -.addSimEntity  (theTag  .  theObject)  ; 
}!/    end  if 

//  if  module  not  loaded 

else  { 

Admin :  loadModule (theTag) ; 

Admin; :addSimEntity (theTag.  theObject) ; 
Ml    end  else 

/  endif 


obje 


tAttributeValu 


oid   AdminFederateAmbassador: 

(    RTI: :ObjeccID  theObject, 

const    RTI:  :  AttributeHandleValuePairSetS.  theAttributes 

RTI:  :  FederationTime  theTime. 

const    RTI : . UserSuppl ledTag  theTag. 

RTI:  :  EventRetractionHandle  theHandle    ) 


t  hr  : 


(ft: 
pt: 
pt: 
pt; 


ObjectNotKnown. 
Attr ibuteNot Known, 
.  InvalidFederationTime. 
FederatelnternalError) 


Admin : :receiveUpdate (theObject.  theAttributes. theTi: 
/  end  ref lectAttributeValues 


. theTag. theHandle) ; 


void  AdminFederateAmbassador 

[  RTI:  :InteractionCl. 

const  RTI:  :Paramet. 

RTI: :FederationTim. 


: receive Interact ion 
ssHandle  thelnterac 
rHandleValuePairSet 
theTime. 


const  RTI :: UserSuppl ledTag  theTag. 

RTI: : EventRetractionHandle  theHandle) 
throw  (RTI;  -InteractionClassNotKnown. 

RTI  :  : InteractionParameterNotKnown, 
RTI :  InvalidFederationTime, 
RTI : : Federatelnterna 1  Error ) 


Admin : : receivelnte 


( thelnteracti 


meters. theTi 


. theTag. theHand 


void  Admi 
theObject 


iFederat-Ambas 


veObjectl    RTI : : ObjectID 

RTI: :ObjectRemovalReason 

RTI : : FederationTime  theTime. 

const    RTI :: UserSuppl iedTag    theTag. 
RTI : : EventRetractionHandle    theHandle 


[RTI: : ObjectNotKnown, 

RTI: :InvalidFederationTim 
RTI : :FederateInternalErro 


//    Call    the    other    removeObject    method    since    this    should   probably 
//      be    implemented   using    default    parameter   values . 


removeObject (theObject.  theReas 

oid   AdminFederateAmbassador :: rem 
throw    (RTI : :ObjeccNotKnown. 


sveOb ject (    RTI : : Obj ectlD    theObject. 
RTI : :ObjectRemovalReason         theReas 


RTI     . InvalidFederationTime. 
RTI     .FederatelnternalError) 


removeObject*    <<    endl ; 

veAmObj  ect I theObj  ect ) ; 


id  AdminFederateAmbassador: :provideAttributeValueUpdate 
(     RTI : :ObjectID  theObject. 

const    RTI : :AttributeHandleSetfc    theAttributes) 


[RTI: 
RTI: 

RTI  . 


ObjectNotKnown. 
Attr ibuteNot Known. 

Federatelnterna 1 Err 


:■ 


void   AdminFederateAmbassador:  :r 
theHandle    ) 

throw    (RTI:  :EventNotKnowr., 
RTI : : Federatelntern 


ctionl    RTI: : EventRetractionHandle 


( 


cerr  <<  "AdminFederateAmbassador : : ref lee t Ret r 

//  I  didn't  implement  this  one  -  sorry! 


//  Ownership  Management  Services  // 
I II 1 1 1 1 1 1 1 11 1 1 1 1 1 1  i  / 1 1 1 1 1 1 1 S 1 1 1  !  1 1 1 

RTI:  :  AttributeHandleSeti. 

AdminFederateAmbassador ; : requestAttributeOwnershipAssumpti 
f  RTI ; :ObjectID  theObject, 

const  RTI  ;  .AttributeHandleSeti.  of  f  eredAttributes  . 
const  RTI ;  UserSuppliedTag      theTag) 
throw  (RTI: : ObjectNotKnown. 

RTI: :AttributeAlreadyOvned. 
RTI i : FederatelnternalError) 


{ 


I  didn't 


npl« 


rry 


it  to  compile  with  the  SparcWorics  compiler 


RTI :  :  Attr lbuteHandleSef  dummy  = 
RTI ; : At tributeHandleSet Factory: :create(0) ; 

return  'dummy, 
) 

RTI : :AttributeHandleSetfc 

AdminFederateAmbassador - : requestAttributeOwnershipAssumptio 
(    RTI: :ObjectID  theObject. 

const    RTI : :AttributeHandleSetfc    of feredAttributes    1 


-h.ro 


(RTI: :ObjectNotKnown. 
RTI : : AttributeAlreadyOwned, 

RTI:  FederatelnternalError) 
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I  didn't  imp !»■ 


r\t  this 


r  r  y  ■ 


//  The  following  is  to  allow  it  to  compile  with  th"  SparcWorks  compiler 

RTI  i  i  Attr  ibuteHandleSet"  dummy  -- 
RTI:  :  At  tnbuteHandleSet  Factory   create  (0 )  ; 

return  'dummy. 
) 

void  AdminFederateAmbassador ; : attr ibuteOwnershipDiv-  'ication 

i  STI   ObjectIO  theObject. 

const  RTI   At tributeHandleSett  releasedAtt r ibutes I 


throw  | RTI 
RTI 
RTI 


ObjectNotKnown, 
Attr ibuteNot Known , 

■  CnternalError) 


I  didn't  implement  thi 


void  Adminr  ederateAmbA:;^ador   attr lbuceOwriT shipAcqu i s  1 1 1 
i  RTI: :ObjectID  theObject. 

const  RTI:  ;  AttnbuteHandleSet*.  securedAt  tribute 


throw  (RTI 
RTI 
RTI 


Ob;ectNotKnown. 
Attr ibuteNot Known. 
Federa te Internal Error  1 


I    didn't    implement    thi 


RTI  :  :AttributeHandleSet(. 

Admin Federa teAmbassador . : request Attr ibuteOwnershipRe lease 
(    RTI :  rObjeetID    theObject. 


const  RTI . 
const  RTI : 
throw    (RTI 

RTI 

pti 


AttributeHandleSeti    Candida teAt  tributes. 
UserSuppliedTag    theTag    ] 

:0bjeetNot Known 
Attr ibuteNot Known. 

: FederatelnternalError) 


U    I    didn't    implement    this    one 


r  r  y  ! 


//    The    following    is   to   a 

RTI     :  AttnbuteHandleSec*    dummy    - 

RTI* :AttributeHandleSetFactory :    create(O) 
return    •dummy; 

) 


t    to    compile  with   the   SparcWorks   compiler 


id  AdminFederateAmba 
(    RTI 
RTI 
RTI 


; informAttributeOwnership 
theObject . 
:  AttributeHandle    theAt tribute. 
: FederateHandle       theOwner) 


throw    (RTI : : Federate Internal  Err 


I    didn't    implement    this   one 


II I  tl  I II I  It  f  II I II I II 1 1 1 1 II I II I 
(I    Time   Management   Services    // 


old   AdminFederateAmbas«ador       t lmeAdvanceCrant 1    RTI     : Federat lonTime    theTime    ) 


throw  (RTI 

RTI 
hT! 

ft: 


InvalidFederat lonTime, 
TimeAdvanceWasNot InPr ogress. 
Federat lonTimeAl ready Passed. 
P*d«rstaXncernal£rror) 


//  Set  the  time  granted 
•  Line  has  changed. 


and  the  flag  to  let  me  know 


//    Admin  :cn3_graneTime     -    cheTlnw; 

//    Admin. :ms_t lmeAdvCrant  =  RTI :  : RTI_TRUE . 


I  i  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  tl  1 1 1 1  i  1 1 1 1 1  i  1 1  i  1 1  i  1 1 1 1 1 1 

II  Data    Distribution    Management       -    NOT    IMPLEMENTED    IN    1.0// 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 II I  H  II 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1  ti  I 

void   AdminFederateAmbassador :    changeThresholds r    RTI:     Region  theRegion, 

RTI: :ThresholdSetfc    theThresholds 

throw    (RTI: : RegionNotKnown. 

RTI: : FederatelnternalError i 
{ 

//    Not    implemented    in    1.0 


//  

//    EXECUTIVE  SUMMARY 

// 

//  File  Name:  amObjeet. h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

// 

//  Description:  pure  virtual  class  defining  the  interface  between 

//     adminModule  objects,  the  federate  Ambassador  and  rti  ambassador 

// 

//  September  1999.  Masters  Thesis 

//  

•include  "npsQua tern ion . h* 
•include  *npsVec3f.h* 
•include  "Rti.hh" 
•include  "ace/OS. h* 

•ifndef  _amObject 
•define  _amObject 

•ifndef  SIM_A?I 
•ifdef  VISUALCPP 

•define  SIM^API  declspec (dllimport ) 

•  else 

•define  SIM_API 
•endif 
•endif 


amObjeet 


cla 

{ 

public: 

//  member  variables 

RTI: :Ob]ectID  entitylD; 

nps Vec3 1  pos i t i on ; 

npsQuatermon  orientation; 

npsVec3f  velocity; 

int  ammunition; 

float  damage ; 

amObjeet (RTI; :ObjectID) ; 
amObjeet  (  ) ; 

//getters  of  Entity  State  fields 


RTI : : Object ID  getEnt ltylD  r I ; 

npsVec3f  getPositior.  i  I  ; 

nps Qua tern ion  getOrientation 

npsVec3f  getVelocity ( ) ; 

int  getAmmunitionf ) ; 

float  getDamage ( ) ; 


(); 


/setters 


of  Entity  Stat 


oid  setEntitylDIRTI : :ObjectID) ; 
aid  set Pos it ion (r.psVec3£) ; 

oid  setOrier.tation(npsQuaternior 


void  setVelocity (npsVec3£) ; 
void  setAmmunitionlint ) ; 
void  set  Damage  (float)  ,- 

/ /  RTI  ambassdor  interface 

virtual  void  sendUpdates [RTI ; : FederationTi 


theTime)  =  0; 


virtual  void  sendUpdates (RTI :  :ObjectID.RTI: : AttributeHandleValuePairSetfc  , 

RTI : : FederationTime,  RTI : : UserSuppl iedTag)  =  0 ; 

virtual  void  sendlnteraction (RTI  :: Interact lonClassHandle, 
RTI;  :ParameterHandleValuePairSet*,.  RTI  :  :  Federat  lonTime. 
RTI : :UserSuppliedTag)  =  0; 

//  FederateAmbassador  interface 

virtual  void  receiveUpdates (RTI : :ObjectID  Old, 
const  RTI : :AttributeHandleValuePairSett  ta. 

RTI :: FederationTime  ft,  RTI :: UserSuppl iedTag  tag)  =  0; 

virtual  void  receivelnteraction (RTI : : InteractionClassHandle, 
RTI: : ParameterHandleValuePairSeti,  RTI: i FederationTime, 
RTI :; UserSuppl iedTag!  =  0; 

virtual  void  receivelnteraction (RTI : ; InteractionClassHandle. 
const  RTI ■ : ParameterHandleValuePairSetfc)  =  0; 

//  Object  display 

virtual  void  displayt)  =  0; 

virtual  amObjeet*  createObject (RTI : :ObjectID)  =  0; 

virtual  void  deleteObject ( )  =  0; 

virtual  char*  getModuleName ( )  =  0; 

virtual  RTI:  Boolean  localObject ( )  =  0; 

virtual  RTI:  Boolean  checlcCollision  (amObjeet  •  that!  =  0; 

virtual  float  checkTerrainCollision (amObjeet*  that)=  0; 

virtual  RTI;  Boolean  isTerrainf)  =  0; 
);  //  end  amObjeet 
•endif 
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//  EXECUTIVE    SUMMARY 

//  File   Name:    amObjecc.c 

// 

//  Author:    CPT   Stewart    Liles 

// 

//  Description   Defi 

//  participating 

// 

'  September  1999.  Masters  Thesi 


si  Postgraduate  School 


•include  -amOb^ect .h" 

amObject -  amOb^ect !RTI  :ObjectID  oid)  { 

entitylD  =  oid. 
)  /  /  end  amObject 
amOb;iect : amObject { ) ( ) 


'IV- 


o£  Entity  St 


fields 


RTI :  : Object  ID   amObject :  :getEntityID()  ( 


npsVec3f 

npstfuater 

npsV*c3f 


amObjecc 
ion  amObject 
amOb] ect 
amOb] ect 
amObject 

if  Entity  Sta 


:  getPosi 
:getOnentation [J (r 
:getVelocity ( ) (retu 
getAnununit  ion  []  (re 
gecDamagef ) (return 

e  fields 


urn  onentati 
velocity; ) 


void  amObject  : 
void  amObject : 
void  amObject  . 
void  amObject . 
void  amObject  : 
void  amObject : 


setEntitylDiRTI : :Ob:ectID  oid} <ent icylD  =  oid;) 
setposition (npsVec3  f  number )  (position  =  number ,  ) 
setOnentation  [npsQuatemion  number) (orientation 
setVelocity (npsVec3 f  number! (velocity  -  number, ) 
setAmmumtion  t  int  number)  (ammunition  =  number;  ) 
set Damage [float  number  1  (damage  =  number ,  ) 


the  module . txt  f o 


Bamboo! . Ob 
4 

npsVisualModule 
bbKeyboardModu 1 e 

npsFlyingCameraModule 
amHLAAdmin 
amChecker board 


the  amBoid 
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amBoid  Files 


// 

It  EXECUTIVE  SUMMARY 

// 

//  File  Name :  module .h 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

//  September  1998.  Masters  Thesis 


•l fndef  module 

■define  module 


INCLUDES  AND  EXTEPNS 


fun-ct i or-:  ppoto-tyfe:  sf ec:f:cation-" 


lfdef  cplusplus 

xtern  -C  { 

endif 

ADMIN_API  const  char  •getModuleName ( } ; 
ADHIN_API  float  getModuleVersion  ( )  ,- 
ADMIN_API  const  char  -getModuleDate ( )  ; 
ADMIN_API  const  char  -getModuleText [ ) ; 
ADMIN_API  bool  initModule  ( )  ; 
ADMIN_API  bool  exitModulet i  ; 


»i f def  cplusplu 

); 
•endif 


INLINED  MEMBER  FUNCTIONS 


endif  / /  module 


EXECUTIVE  SUMMARY 
File  Nana   modulo . c 

Author   OPT  Stewart  Lilei   Naval  Postgraduate  School 

Description   l<  da  prrun*nt  to  module  loading  and  unloading 

September   :•<■-   ".>/-:■  T.-v.i:. 

INCLUDES  AND  EXTERNS 


nclude  <stdio.h> 
nclude  <stdlib  n ■     itol 
nclud-  'module  h  * 
nclude  "amBoid. h* 


cons:  Char  'getModuleName [ ) 
t 

return  "amBoid" . 
I 

float  getHoduleVersioni ) 
t 

return  1.0; 
) 

const  char  'getModuleDate ( ) 
{ 

return  "1998/09/01  06:05  48-. 
) 

const  char  *getModuleText ( } 
( 

return  "This  is  a  really  nice  module 
> 

bool  initModulel) 
{ 

initamBoidf  1  . 
return  1; 


bool  exitModulei) 


exitamBoid ( ) , 
return  1 : 


It         EXECUTIVE  SUMMARY 

'/  File  Name:  amBoid  h 
/' 

thor:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

if    Description:  defines  methods  pertinent  to  module  loading  and  unloading 

'■  September  1999,  Masters  Thesis 


>i  fr.def  _amBoid 
■define  „amBoid 


//    INCLUDES  AND  EXTERNS 


//    FUNCTION  PROTOTYPE  SPECIFICATIONS 


void  i.-iitamBoid!  1  , 
void  exitamBoid! ) , 


//    INLINED  MEMBER  FUNCTIONS 


//  

//    EXECUTIVE  SUMMARY 

// 

//  File  Name:  amBoid.h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

// 

//  September  1999.  Masters  Thesis 

//  


■ifndef  _amBoid 
•define  _amBoid 


//    INCLUDES  AND  EXTERNS 


//    FUNCTION  PROTOTYPE  SPECIFICATIONS 


void  initamBoid!) ; 
void  exitamBoid!)  ,- 


//    INLINED  MEMBER  FUNCTIONS 


// 


//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  amBoid. c 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

//  Description:  defines  methods  pertinent  to  module  loading 

//  September  1998.  Masters  Thesis 


// 


INCLUDES  AND  EXTERNS 


•include 

"Rti.hh* 

■include 

"amBoid . h" 

•include 

•npsVisual ,h" 

•include 

"npsWindow. h" 

•include 

"npsViewport .h" 

•include 

"npsFlymgCatnera  .  h 

•include 

"bbMouse .h* 

•include 

"bbScreen. h" 

•include 

-bbKeyboard.h" 

•include 

"bbEventResponse  h 

•include 

■bbCallback.h" 

•include 

"npsGeometry . h" 

•include 

'boid.h' 

•include 

"amHLAAdjnin.h" 

•include 

•admin. h " 

■include 

"amObject .h" 

■include 

<math.h> 

■include 

<CL/gl.h> 

■ifdef  SGI 

•  inclut 

e  "bbSGI.h" 

•endi t 

Bold  "my  Bo  id,-  //  global  local  object 


//function  prototype 
int  mouselnWindowf ) ; 


//  runcti 

3n  Name 

initamBoid 1 ] 

//  Task: 

initia 

ize  Hodule  -- 

//  Return 

Value: 

void 

ir.itamBoidl )  < 
oid  initKeyboardModule [] 


58 


/oid 

in 

cVisualModule 

■ 

myBoid 
Admin  :■ 

new  Bold  I ) . 

ddModuleFuncti 

onPoinc- 

lmyBo 

d 

initKeyboardModi-le : 

my  Bo 

d 

NULL, 

COUt 

« 

"amBoid  Modui* 

leaded- 

<<    »ndl 

i'  Function  Name;  exitamBoidl) 

■  Task-   does  housekeeping  required  Co 
//     this  is  run  only  onc- 

II  Return  Value:  void 


id  exitamBoidl ) ( 

bbCallbackHandier 

uint 

u  i  n  t 

bbCallback 

u  i  n  : 

npsGeometry 

bbKeyboard- 

bb Event Response" 


'calibackHandle 
numCallbacks ; 
currCallback. 
callback, 
currDuck ; 
•duck. 
keyboard; 
eventResponse ; 


;/  remove  keyboard  callbacks 

/ /  RESET 

eventResponse  =  bbEventResponse : :  f  mdObject  (  "amBoidER 

callback  =  bbCallback  :  ;f  mdObject  {  "amBoidReset*  )  ; 

eventResponse- >removeCal lback [callback) ; 

delete  callback. 


//  remove  keyboard  callbacks 

//  LoadBoid 

event Response  =  bbEventResponse; : f mdObject ( *amBoidER_LoadBoid" ) ; 

callback  =  bbCallback  :  :  findObject  (  •amBoidLoadBoid"  >  .- 

event Response- >removeCa 11 back  lea  11 back) . 

delete  callback; 


/ /  first  remove  update  cal lback 
callback  =  npsVisual :: appCallback <)  ; 

callbackHandler  =  cal lback- >getPreCallbaekHandler (> ; 
callback  =  bbCallback :: f mdObject [ "BoidPreApp" ) , 
if (callback) { 

callbackHandler->removeCal lback (callback) . 

delete  callback; 
)//end  if 


mdSimEnt  i  ty '. 


mBoid" 


■  ■  remove  remote  am1  I 
amobject ■  theobjecc 
while  I theObject ) ( 

Adsi  i  n   r -move AmOb  jee<  -get  En  t ity ID  I  .  .  . 

theOb}*ct  -  Admin   f indSimEntity I "amSoid" I ; 
) 

-  •  he  module  (row  tnod 
Admir.   removeModuie  ( *amBoid"  ,  ; 


//  Function  Kane   initKeyboardModule 
//  Task.    add  keyboard  cal.i  - 
//  Return  Value   ■--.,,  I 


id  initKeyboardModule!)  ( 

void  escFunc IbbObject  'object,  bbDato  'datai. 
void  reset Func IbbObject  'object,  bbData  'data ) , 
void  loadBoid IbbObject  'object.  bbData  'data); 


bbKeyboard 

bbEventRespons 
bbCallback 


•keyboard. 

'eventPespons 

•callback. 


//  get  the  keyboard  device 
keyboard  =  bbKeyboard:  :getlns 


- 


//  set  up  reset  key 

eventRespor.se  =  new  bbEventResponse  (bbKeyboard  :KEY_SPACE)  ; 

eventResponse->setName ( *amBoid£R_Res-- " 

callback  =  new  bbCallba 

ca 1 lback- > set Func (resetFunci  , 

callback- > set Name ( 'amBoidReset* ) , 

event Response- >addCallbackLast (cal lback  I  . 

keyboard -> add Event Response  I  event Response  I  , 

//  set  up  load  bold  key 

eventResponse  =  new  bbEventResponse (bbKeyboard :: KEY_B  | 
bbKeyboard: :DOWN_TRANS] , 

eventResponse- >setName ( "amBoidER_LoadBoid' I , 
callback  =  new  bbCallback!), 
ca 1 lback -> set Func (loadBoid) . 
callback->setName I -amBoidLoadBoid" ) ; 
eventResponse- >addCallbackLa st (callback) ; 
keyboard->addEventResponse (eventResponse) ; 


)//end  initKeyboardModule 


//  Function  Nam 
//  Task.:  attac 
//  Return  Value 


initVisualModule( ) 

callback  to  PreApp  callback  handler 


Visula  Module 


ad  mitVisualModuleO  ( 

void  initCheckerboardFunc (bbObject  "object,  bbData  -data), 
void  preAppFunc IbbObject  'object.  bbData  'data); 


npsWmdow 

•window; 

npsViewport 

• v i ewpo  r  t ; 

npsCamera 

•camera ; 

bbEventResponse 

•eventResponse 

bbCallbackHa 

ndler 

•callbackHandl 

bbCallback 

•callback; 

npsVec3f 

position. 

npsQuaternic 

rotation; 

npsGeometry 

•checkerboard. 

//  pre  app  callback 

callback  =  npsVisual :  rappCallback  I  ) ; 

callbackHandler  -  callback- >getPreCallbackHandler  [)  ; 

callback  =  new  bbCallback <) ; 

callback->setName ! "BoidPreApp* ) ; 

callback->setFunc (preAppFunc) ; 

callbackHandler->addCalibackLast (callback) ; 


Function  Name:  preAppFunc IbbObject  'object.  bbData  'data) 
Task:   defines  preApp  ca 1 lback  function  -  - 

uses  keyboard  controls  to  maneuver  Bold 

checks  for  collisions 
Return  Value:  void 


id  preAppFunc IbbObject 

void  deleteMyBoidd  , 

float  cos 

bbKeyboard        "kd; 

npsCamera         "cam 

npsVec3f 

npsOuaternion 

npsVecJ  f 

float 


f  1  o 


tmpVec ; 
hprUJ; 
velocity  =  0; 


kd  -    bbKeyboard: :get Instance! ) , 

camera  =  npsCamera   f indObject I "AdminCa 


/ /don  *  t  do  anything 
if (myBoid) ( 


nless  there 


al  bold  to  control 


osition  =  myBoid->getPosition( 
otation  =  myBoid->getOrientati 
otation  getEulers Ihpr I ; 


//  Need  this  to  cont 
//  key  commands  won' 
//  is  in  the  window 


ol  each  window  separtely 
work  unless  the  mouse  po 


heading  left1* 


imouselnWmdowu  )  ( 

if  i  kd->getVal (bbKeyboard: ; KEY_LEFTARROW) 

hpr[0J  •=  NPS_DEC2RAD(4.0f) ; 

if  [hpr[0]  >  NPS_?I) 

hpr[0]  -=  2.0f'NPS_PI; 
) 
if  I  kd->getVal [bbKeyboard:  KEY.RIGHTARROW)  )  [  //  heading  right' 

hpr[0}  -=  NPS_DEG2RAD(4.0f); 
if  (hpr(01  <  -NPS_PI) 

hprlO]  -=  2.0f*NPS_PI; 
) 
if  (  kd->getVal (bbKeyboard : :KEY_UPARROW)  )(   //  pitching  up' 

hpr(l)  *-  NPS_DEC2RAD(4.0f ) ; 

if  (hprdl  >  NPS_PI'0.*9Sf ) 

hprtll  =  NPS__PI'0  49Sf; 


pitching  down? 


if  (  kd->getVal (bbKeyboard : :KEY_DOWNARR0W)  ){ 

hprtl]  -=  NPS_DEG2RADl4.0f); 

if  (hpr[l)  <    -NPS_PI"0.495f) 

hprfl]  =  -NPS_PI'0.495f ; 


setEulers I hpr ) . 


//  update  velocity 

if  (  kd->getVal  (bbKeyboard:  :KEY_S)  fci.  kd->getVal (bbKeyboard: : KEY_A; 
dead  stop 

velocity  =  O.Of; 
else  if  I  kd->getVal (bbKeyboard: :KEY_S)  )   //  accelerate 

velocity  *=  l-2f; 
else  if  (  kd->getVal (bbKeyboard: :KEY_A)  )  II    decelerate 

velocity  -=  1.2f; 
else  (  //  slow  down 

if  (velocity  >=  O.lf) 
velocity  -=  O.lf; 
else  if  (velocity  <=    -O.lf) 
velocity  -=  O.lf; 


59 


else 

myBoid- > set Or lentation (rotat ion) , 

velocil . 

1 

c«mera->aetPosit lonipocit :oni . 
camera- >setOr lentation (rotation) . 

:  Of  )                  if  i    -  locity  -2  *=    v 

: 

velocity  i  2.0(; 

■locity  <- 

else  if   vel  >city  <=>  -2. Of) 

ft   boid  no  collision 

velocity    -2 .Of; 

else  if (old  ==  0) ( 

tmpVec  set (O.Of   0  Of,  -1  Of  .   //  forward 
tmpVec. scale (velocity] . 

)//  end  if  mouaelnWindow 

rotation  . xform ( tmpVec i . 

position. add (tmpV-        ie(  v«c3 f 

//  updat-  position 

static  RTI  ;  :Ob)«ctID  oid  =    0; 

myBoid- > set Velocity [tmp\  ■ 

Old  =  0. 

myBoid->set Posit  ion (position) ; 
myBoid- >cetOr lentation (rotation) ; 

//  entity  collision 

camera->secPosition (posit  ion)  ; 

oid  =  myBoid->ha&CoIlid'-d(l  , 

camera- >setOnentat  ion (rotation)  . 

float  yPos  -  0.0. 

RTI  ;:  Boo  lean  terramFeacureCollision  =  RTI :  RTI_FALSE, 

■end  else  if 
//  boid  collided  with  entity 

ieck  collision  with  terrain 

else! 

if  (Admin  :IBS_Tei 

tmpVec. set (O.Of,  O.Of.  -1  .  Of  1  ;   //  forward 

yPos  =  Ainir,  y±_7rrz  ain->checkTerramCollision  (myBoid)  . 

tmpVec  scale (velocity) , 

terramFeatureCollision  =  Admin:  'ms_Terrain->checkCol  lisi 
) 

sn (myBoid) . 

rotation  xform (tmpVec 1 , 

position . sub (tmpVec )  ;  //  set  vec3f 

position  sub (tmpVec) ; 

//  terrain  is  returning  a  y  Position 

if  (yPos  •  -  0 

myBoid->setVelocity (tmpV-T } , 
myBoid->setPosition (position) ; 

tmpVec .set (O.Of.  0  .Of ,   L  Of J ,      forward 

myBoid->setOrientation  (rotation)  ,- 

tmpVec . scale (velocity  I  . 

camera->setPosition (position) ; 

rotati on. xform  [tmpVec)  .- 

camera->setOnentation  (rotation)  ; 

posit  ion. add (tmpVec) .  /'    set  vec3f 

position . set (1 . yPos) . 

cout  <<  'Collided  with  entity  *  <<  oid  <<      endl; 

myBoid->setVeiocityl tmpVec) . 

FT!   FederationTime  th-Time  =    0.0; 

myBoid->setPosition(position)  . 

my Bo id- >sendCol lis ion Interact  ion ItheTime. oid) ; 

myBoid ->setOnentat  ion  (rotation]  ; 

J //end  else 

camera->setPosition(posit ion)  , 

camera -> set Orientation (rotation) ; 

//  check  if  Boid  is  destroyed  in  some  way 

if (myBoid- >getDamage ( 1  <  OH 

)//end  if 

deleteKyBoidO  ; 

//  bold  collided  with  terrain  feature 

) 

else  if (terramFeatureCollision) ( 

)//  end  if  myBoid 

tmpVec . set ! myBoid - >getVeloci ty ( ) ) ;   //  forward 

/ /  tmpVec . scale (velocity l . 

} / /  end  preAppFunc 

rotation. xform (tmpVec) j 

position . sub (tmpVec) .  /  /  set  vec3f 

position . sub (tmpVec) , 

posit  ion. sub (tmpVec]  .  //  set  vec3f 

/ /  Function  Name   resetFunc (bbObject  'object .  bbData  "data) 

position. sub (tmpVecl . 

//  Task:   function  defined  for  the  resetBoid  keyboard  callback 

position. sub(tmpVec) ,  //  set  vee3f 

//  Return  Value:  void 

myBoid->setVelocity (tmpVecl ; 

myBoid->setPosition(positionl ; 

void  resetFunc (bbObject  "object.  bbData  "data)  ( 

npsCamera  *              camera ,- 

bbScreen:  :  normal izeVal  (S.x.  fcy)  ; 

npsVec3f               ini  t  Posit  ion  .- 

npsQua tern ion          ini t Rota t ion ; 

if  (viewport->getWindow[ ) ->isVal Inside (x. y) 1 { 
flag  =  1; 

if  [mouselnWmdowO  44.  myBoid)  ( 

) 

return  flag; 

initPosition.set (O.Of.  3. Of.  -10. Of); 

)//end  mouselnwmdow 

initRotation.setEulers(NPS_DEG2RAD[180.0£) .O.Of. O.Of); 

myBoid ->set Posit ion ( initPosition) ; 

void  deleteHyBoidl )  { 

my Bo id ->setOr lentation ( in it Rotation) ; 

bbCallbackHandler       'callbackHandler ; 

)//  end  if 

bbCallbaek               "callback. 

)  //  end  resetFunc 

Admin:  :  removeAmObjeet  (my3oid->getF-ntityID  ( )  )  ; 

myBoid  =  NULL; 

//  Function  Name:  loadBoid (bbObject  'object.  bbData  "data) 

//  Task:   function  defined  for  the  loadBoid  keyboard  callback. 

//  Return  Value:  void 

)//end  deleteMyBoid 

void  loadBoid (bbObject  'object.  bbData  'data)( 

void  initVisualModulel)  ; 

i  f  (mouselnWmdow  | )  )  ( 

cout  <<  'loadBoid'  <<  endl; 

if ( -myBoid) ( 

initVisualModulel) ; 

RTI : TObjectID  oid  =  Admin: : registerObject  1  ) ; 

amObject'  tmp  = 

Admin: :addSimEntity ( 'amBoid* .  oid) ; 

myBoid  =  (Boid' ) tmp; 

myBoid- >setLocalObject (RTI :  RTI_TRUE) ; 

)//end  if 

)//end  if 

)//  end  loadBoid 

//  Function  Name:  mouselnWindowf ) 

//  Task:   tells  if  mouse  is  in  the  correct  window  to  receive  keybo 

ird 

//     commands 

//  Return  Value:  int  representing  boolean 

int  mouselnWindowl )  ( 

int  flag  =  0; 

npsWindow               •window; 

r.ps  Viewport              'viewport; 

window  =  npsWmdow:  :  f  mdObject  (" AdminWindow"  )  ; 

viewport  =  nps Viewport :  \  f  mdObject  {  'Admin Viewport"  J  ; 

float          x.y. 

x  =  bbMouse:  :getX()  ,- 

y  =  bbMouse : :getY () ; 
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EXECUTIVE  SUMMARY 
II    File  Name   Boid.h 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 
//  Description   defines  bold  class 
September  1996,  Masters  Thesis 


include  "Rci.hh" 
include  -npsVec3 £  h" 
mclude  'npsGeometry .  h" 
include  -bbKeyboard  h* 

mclude  *amOb)ect  .  h* 
include  * admin . h" 


ifndef  ADMIN_API 
iifdef  VISUALCPP 

•define  ADMIN_API  declspec (dl limpor 

•  else 

•define  ADMIN_API 
liendif 
endif 


static  RTI : :Boolean  ms_sendRotat lonUpdates . 
static  RTI  Boolean  ms.sendPosit lonUpdaces , 
static  RTI   Boolean         ms_sendCommInteract ions, 

/   member  functions 
public 

Bold  i  )  , 

Boidf  RTI:  :Ob)ectID   idl  , 

void  setLocalOb^ect I RTI  :  Boolean; ; 

RTI:  -ObjectID  hasCoUided  (  )  . 

virtual  -Boid [ j ; 

.  i 

virtual  amOb^ect*  createObject [RTI : :ObjectID  oidj . 

virtual  void  deleteObject ( J ; 

virtual  char*  getModuleName ( I . 

virtual  RTI::Boolean  localObject ( ) . 

virtual  RTI  .Boolean  isTerrami); 
//  Methods  acting  on  tne  RTI 


ADMIN.API  Bo 


public  amOb^ect 


endUpdates (RTI ■ : Fede 


onTi 


/.'memeber  variables 
pub lie: 

ACE_Recursive_Thread_Mutex  theMutex, 

ii    time  management  data  memebers 
static  unsigned  int    ms_extentCardmality  -. 
static  RTI: -Boolean    ms_t imeAdvGrant . 
static  RTI: : FederationTime   ms_grantTime . 
static  char*  ms_ModuleName . 


RTI: : FederationTime    m_lastTime; 

npsGeometry*  myCeom. 

//  Change  flags  for  attibute  value 


RTI: :Boolean 
RTI: : Boolean 


RTI : : Boolean 


hasPositionChanged, 
ha sRotat ion Changed, 


sendUpdates  [RTI  :  .Object  ID.  RTI   At  tributeHandleValue  Pair  Set  (. . 
RTI  -FederationTime.  RTI:  UserSuppliedTag); 

virtual  void     receiveUpdates { RTI : :ObjectID  oid. 

const  RTI  .  ;AttnbuteHandleValuePairSet*.  hvps. 

RTI: : FederationTime  ft.  RTI ; : UserSuppl ledTag  tag). 


void      sendCollisionlnterac 
ewTime.RTI: :Ob]ectID  Old), 


i  (RTI :  : Federat lonTim 


virtual  void      sendlnteract ion 1RTI : : Interact lonClassHandle 
RTI : : ParameterHandleValuePairSetfc.  RTI: : FederationTime, 

RTI : : UserSuppliedTag) ■ 


virtual 
thelnteract 


id  receivelnteractiont  RTI : : InteractionClassHandle 
const  RTI : :ParameterHandleValuePairSeti  theParameters  ); 


virtual  void  receivelnteraction  [RTI  :  : InteractionClassHandle 
RTI: :ParameterHandleValuePairSet4  phvps,  RTI: federation 
RTI :: UserSuppliedTag  tag); 


si  RTI-Boolean  checkColli 
al  float  checkTerrainColli 


i  [amObject  *  that ) , 
i  (amOb^ect*  that ) ; 


/ /  Accessor  Methods 

//  Static  Accessor  Methods 

RTI : : Federat lonTime 


GetLastTime ( ) 

{  return  m_lastTi 


pri 


void  initBoidGeometry  () ; 

static  void  mitBoidFunc  (bbObject  "object,  bbData  -data); 

float  distanceFrom(npsVec3f  thatPos) ; 
protected : 

RTI : :AttributeHandleValuePairSet*    CreateNVPSet ( ) ; 
); 


//  

//  EXECUTIVE  SUMMARY 

//  File  Name :  Bo id . c 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description:  method  definitions  for  the  Boid  class  -- 

//  Boid  class  represents  the  class  that  is  implemented  by  the  amAre 

//  module. 

//  September  1998,  Masters  Thesis 


include  "RTI.hh* 
include  'boid.h* 
include  'npsGeoroetry .  h* 
include  'bbKeyboard . h* 
mclude  <GL/gl.h> 
include  "admin . h" 
include  "amObject . h" 
include  "amHLAAdmin . h" 


//  Extent  data  memebers 

nsigned  int    Boid : :ms_extentCardinality  =  0; 


char*  Boid: :ms_ModuleName  =  "amBoid"; 


i  i  II 1 1 1 i I ! i 1 1 ! ! 1 1 1 i I  It  1 1 1 i I ! 1 1 i! 1 1  /1 11 
I 1    Const ruction /Destruction 

1 1 1 1 1 1 1  u  1 1 1 1 1 1 1 1 1 1 1 1 ;  1 1 1  n  1 1 1 1 1  ii  / 1 1 1 


1 1 1 1 1 ii 1 1 1 1 1 1 1 1 1 1 1 1 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


1 1 1 1 1 1 1 1 1 
1 1 1 1 1 1 1  n 


II    Function  Name  Boid!  RTI :  :Ob]ect.ID   id] 
II   Task-   constructor  —  instance  intialize 
//  Return  Value:  void 


3oid::Boid[  RTI: :ObjectID   id) 
:m_lastTime(0.0) { 


setEntitylDIid] ; 
npsVec3f  xx; 
xx. set (O.Of.O.Of .  0.  Of  )  ; 
setPosition [xx) , 
npsQuatemion  yy. 
setOrientation(yy) ; 

setDamage(lO.O) ; 

localFlag  =  RTI : :RTI_FALSE; 

initBoidGeometry ( ) ; 

Boid:  :ms_extentCardinality- ; 
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.■'  Function  Name :  Bo  i  i 

constructor  --  used  (or  object 
//  Return  Value :  void 


Boid:  Soldi ) 
ir_lastTl 


'■  Function  Name:  -Boidt 
destructor 

Return  Value   void 


Boid;  -Boidl) ( 

//  remove  the  Object  from  the 

.  extentCardinality--; 
;£ (myCeoml 

delete  tnyGeom. 

} I t    end  destructor 




'/  Function  Name   sendUpdates (RTI :  ObjeetID  Old. 
RTI   AttnbuteHandleValuePairSetfc  ta. 
RTI   FederationTime  ft.  RTI ■  UserSuppliedTag  tag) 
Task :   not  implemented  in  this  module  --  pure  virtual  funct ion 
t .     have  definition 
/ i    Return  Value:  void 




id  Boid: 

RTI: 

RTI 


sendUpdates(RTI : :ObjectID  oid. 
AttnbuteHandleValuePairSetfc  ta. 

FederationTime  ft.  RTI : : UserSuppl ledTag  tag] 


(I    Function  Name:  sendUpdates (RTI :: FederationTime  newTime) 

ft    Task:   send  handle  value  pair  to  rti  for  update  to  federati 

//  Return  Value:  void 


id  Boid: : sendUpdates (RTI: : FederationTime  newTime) ( 
Update  state  of  Boid 


RTI   A-  -  ributeHandleValuePairSet*  pNvpSet  ■  CreateNVPSet () ; 

Admin:  sendEnt ityUpdate <  get Ent l tylD I , . "pNvpSet .  getModuleName [ ]  ); 


I    set  m.lastTime  to  newTi 

_lastTim-  -  n-wTim*. 


)//  end  sendUpdate 


Function  Name   receiveUpdates <  RTI .: Object  ID  old. 

const  RTI  :AttributeHandieValuePairSetl.  theAttributes. 

PTI  : FederationTime  theTime,  RTI:  UserSuppl ledTag  theTag) 
Task    decodes  HVP  from  RTI  for  this  object 
Return  Value:  void 


id  Boid  : receiveUpdates (  RTI  -ObjectlD  old. 

const  RTI   AttnbuteHandleValuePairSetfc  theAttributes. 

RTI  : FederationTime  theTime,  RTI ;: UserSuppl ledTag  theTag) ( 


RTI ; AttributeHandle 
unsigned  long 


aed 


ttrHandlej 

alueLength. 


rate  through  the  Attr ibuteHandleValuePalrSet 
/  to  extract  each  Attr ibuteHandleValuePair .   Based  on  the  type 
/  specified  (  the  value  returned  by  getHandlet)  )  we  need  to 
/  -xtract  the  data  frlom  the  buffer  that  is  returned  by 
/  getValu- : i 
or  (  unsigned  int  i  =  0.  i  <  theAttributes . size i | .  i*«  | 

attr Handle  -    theAttributes  . get Handle (  i  ) ; 

if  (  attrHandle  ==  Admin  :: getPos it lonAttrHandle ( 1  ) 

( 

npsVec3  f  tmp; 

theAttributes .get Value [ 

setPosition (tmpl ; 
)//end  if 


else  if  I  attrHandle 


A  dm 


( 


/ /  Same  as  above  goes 
npsQuatemion  tmp. 
theAttributes .getValu 
setOrientation(tmpl ; 
)  //  end  else  :£ 


(char*)fctmp.  valueLength  ); 


:getOrientationAttrHandle | ;  ) 


(char*}fctmp. 


els 


attrHandle  =-  Admin :: getVelocityAttrHandle ( ) 


//  Same  as  above  goes  here. . . 

npsVec3  f  tmp; 

theAttributes  .get  Value  (  i.  (char*)  i.  tmp. 

setVelocity (tmp) ; 
]//  end  else  if 


alueLength  )  ; 


//  end  for 

nd  recevieUpdates 


Function  Name:  receivelnteraction (RTI : : InteractionClassHandle  ich. 

RTI:  ParameterHandleValuePairSetfc  phvps.  RTI :: FederationTime  ft, 

RTI :: UserSuppl ledTag  tag] 
Task:   not  implemented  in  this  module  --  pure  virtual  function  must 

have  definition 
Return  Value:  void 


oid  Boid: : receivelnteraction (RTI:  : Interact lonClassHandle  ich, 

RTI : : ParameterHandleValuePairSetfc  phvps.  RTI : : FederationTim 
RTI :: UserSuppl iedTag  tag) 


Function  Name   receivelnteraction! 

RTI : : InteractionClassHandle  thelnteraction. 

const  RTI : : ParameterHandleValuePairSetfc  theParamet 
Task:  recieves  PHVP  and  decodes  for  use  with  module 
Return  Value:  void 


id  Boid  :  .receivelnteractiont  RTI :  : InteractionClassHandle  thelnteraction, 
const  RTI: ParameterHandleValuePairSetfc  theParameters  ]( 

if ( thelnteraction  ==  Admin: :getCollisionInteractionHandle ( ) ) ( 
setDamage fgetDamagel )  -  1.0); 

cout  <<  '"Collision  Detected  --  Object  "  <<  getEntitylDt ) 
«    *  Damage  =  "  <<  getDamageO  <<  endl; 


J //end  receivelnter 


//  

//  Function  Name:  sendCollisionlnteraction (RTI :: FederationTime  theTi; 

//  RTI: :ObjectID  oid] 

//  Task:   sends  rti  the  PHVP  using  the  send  interaction  fucntion 

//  Return  Value:  void 

I !  

void  Boid: : sendCollisionlnteraction (RTI : : FederationTime  theTime. 
RTI: :ObjectID  Old) { 

//build  paramter  handle  value  pair 
RTI: :ParameterHandleValuePairSet •  params  = 
RTI: : ParameterSet Factory: :create(l) ; 


params- >add (Admin:  : get Ent ityldHandle ( ) ,  (char* ) fcoid. 
sizeof (RTI : :ObjectID) ) ; 


sendlnteraction [Admin:  : getCo 11  is ion Interact ionHandle f I 
theTime. NULL) ; 


)//end  sendColli 


//  Function  Name:  sendlnteraction (RTI :: FederationTime  ft) 
//  Task:   send  the  PHVP  for  the  given  interaction 
//  Return  Value:  void 


void  Boid 
RTI 

RTI 


sendlnteraction (RTI : : InteractionClassHandle  lhc, 
ParameterHandleValuePairSetfc  phvps.  RTI  :: FederationTime  ft. 
UserSuppliedTag  tag) ( 


tryt 

Admin  :  :ms_rtiAaib->send  Interact  ion  (  ihc  ,  phvps,  ft ,  tag)  ; 


catch (RTI :: Exception*  e) ( 
cerr  <<  &e  <<  endl; 


)//end  sendlnteractio 


//  Function  Name:  CreateNVPSet [ ) 

//  Task:   creates  HVP  set  pertinent  to  this  object 

//  Return  Value:  AttributeHandleValuePairSet* 


RTI   AttributeHandleValuePairSef  Boid; : CreateNVPSet ( ) { 

RTI: : AttributeHandleValuePairSef  pBoidAttributes  =  NULL; 


//  Make  sure  the  RTI  Ambassador  is  set 
if  (  Admin : :ms_rtiAmb  ) 


//  Set  up  the  data  structure  required  to  push  this 

//  objects's  state  to  the  RTI. 

// 

RTI : : Object IDcount  numAttributes (3)  ; 

pBoidAttributes  =  RTI ::  AttnbuteSetFactory:  :  create  (  numAttributes  )  ,- 

pBoidAttributes- >add  i  Admin: : getOrientat ionAttrHandlet )  , 
(char*)  fcorientation. 
sizeof (npsQuaternion)  ) ; 

pBoidAt tributes- >add [  Admin:  : get Posit lonAttrHandle ( )  , 
[char* ) iposition, 
sizeof  InpsVecSf )  )  ; 
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pBoidAttributes->add  (  Admin  :  :  get V- loci  tyAttrHandle  [  t  . 
ichar* ) ^velocity . 
sizeof fnpsVec3f:  ) . 


return  pBoidAt tributes 
)//  CreateNVPSet I i 


//  Function  Name   display! I 

//  Task:   updates  geometry  pos 

//  Return  Value   void 


void  Boid:display[)[ 

myGeom->setPosition [get  Position ( 
myCeom->set Orientation ( getOrient 

)//  end  display- 


Function  Name :  createObject ( RTI : . Object ID  oid) 
Task:  creates  an  object  and  returns  a  pointer 
Return  Value   amOb;ject* 


amQbjecf  Bold  :  -createObject  (RTI  :  :  ObjectID  oid){ 

Boid'  tmpBoid  =  new  Boidloid); 

return  I amObject* ] tmpBoid, 
)//end  createObject 


//  Function  Name  deleteObject  I ) 
//  Task:  remote  delete  function 
//  Return  Value:  void 


void  Boid: :deleteObject ( ) t 
delete  this; 


//  Function  Name  getModuleName!) 

//  Task:   accessor  method  for  module 

//  Return  Value   char" 


char*  Boid:  : getModuleName ( )  ( 

return  Boid: :ms_HoduleName 
) / /  getModuleName 


/ '  Function  Namr   initBoidFunc IbbOoject  * object .  bbDat 
//  Task    defines  function  for  geometry  callback 

//  Return  Value   void 


id  Boid:  :  mitBoidFune  (bbObject  "object,  bbData  *datai{ 

GLfloat  coords[4J[3]  =  {  {  O.Of.  O.Of.  -0.9f).   //  front 

(-0.6£.  0  Cf.  C  9f)  Dack  left 
[O.Sf  Co:".  0.9f),  f,  d,ic<  right 
<  C  Cf.  0  r>t.  0.9£)      //  top 

); 

glShadeHodel (CL.FLAT) ; 
glBeg in (GLJTRI ANGLES)  . 
( 

glCoicr3f (O.Of .  O.St,  1.0ft;     //  bottom 

glVertex3£v [coords(0] ) ; 

g!Vertex3fv(coords[2) ) ; 

glVertex3fv(coords[l] ) , 

glColor3f C  Of .  O.Sf.  O.Of);     //  left 
glVertex3fv(coords[0] ) . 
glVertex3:v(coords[l]  )  ; 
glVertex3fv(coords(31  )  ; 

glColor3f (l.Of.  O.Sf.  I. Of);     ft    right 
glVertex3fv[coords(0] } . 

g!Vertex3fv(coordsl31 ] , 
glVertex3fv (coords [2  1 ]  . 

glColor3£[0.0f .  O.Sf.  O.Of);     //  back 

glVertex3fv(coords[i; : 

glV*rtex3fv [coords [2] ) . 

glVertex3fv (coords [2 ]  )  . 
) 

glEnd  ()  ; 

glShadeModel(GL_SMOOTH) ; 
/end  initBoidFunc 


Function  Name:  mitBoidGeo 
Task    attaches  the  functi 

Return  Value:  void 


for  geometry  callback  to  the  Vi 


id  Boid:  :  mitBoidGeo 


myGeom  =  new  npsGeometry (Boid :: mi tBoidFunc) ; 
myGeom->setBoundingSphere lnpsVec4f (O.Of.  O.Of.  O.Of.  l.Of)  i  . 


end  m i t Bo idGeome t  ry 


//  Function  Name:  setLocalObjeet (RTI :: Boolean  flag) 
//  Task:   set  the  object  as  local  or  not 
//  Return  Value:  void 


id  Boid: : setLocalObjeet (RTI : :Boolean  £lag){ 
localFlag  =  flag. 


//  Function  Name:  localQbject  [  ) 

//  Task:   accessor  method  for  local  object  flag 

//  Return  Value:  Boolean 


RTI : : Boolean  Boid: : localObject { ) ( 
return  localFlag; 


//  Function  Name:  isTerramO 

//  Task:   informs  amHLAAdmin  whether  the  object 

//  Return  Value:  Boolean 


terrain  object  or  not 


RTI  :  :Booleari  3oid::isTer 

return  RTI : : RTI_FALSE 


//  Function  Name:  checkCollision (amObject*  that) 

//  Task:   returnds  true  if  there  is  a  collision  with  this  obje 

//  Return  Value:  Boolean 

//  

RTI :  :  Boolean  Bold-.  rcheckCollision  [amObject *  that)  [ 
RTI:: Boolean  flag  =  RTI : : RTI_FALSE, 
if  (that  '=  this)  ( 

if (distanceFrom[that->getPosition [) )  <  2 ) ( 

flag  =  RTI: :RTI_TRUE; 
)//end  if 
)//end  if 
return  flag; 
)//end  checkCollision 


//  Function  Name:  hasCollided!) 
//  Task:   checks  if  current  obje 
//  Return  Value:  ObjectID 


RTI ; : Object ID  Boid: : hasCollided ( ) ( 


ollided  with  any  other  obaject 


//  loop  amObject  array 

//  compute  distance 

RTI: :ObjectID  oid  =  0; 

amObject*  tmp  =  Admin :  :check£ntityCollision ( this)  ; 

if  (tmp  fc&  (tmp  !=  this)  ){ 

if ( I ( tmp- >get Velocity!) ) -  length ( >  <  (this->get Velocity  [ )  )  .length! 1  )  j { 
oid  =  tmp->getEntityIDl ) ; 

)//end  if 
}//end  if 


}//end  hasCollided 


Function  Name:  di 
Task:  finds  dist 
Return  Value:  flo 


anceFrom(npsVec3f  that Pos 
ce  between  two  objects 


float  Boid: :distanceFrom(npsVec3f  thatPos){ 

npsVec3f  thisPos  =  this->getPosition ( ) ; 

npsVec3  f  tmpPos ; 

tmpPos.sub!  thatPos.  thisPos)  ,- 

return  tmpPos  .  length  ()  .- 

>//end  distanceFrom 


//  

//  Function  Name:  checkTerrainCollis 

I!  Task:   returns  y  value  for  terrai 
//     collision  detection  --  0.0  bee 

//  Return  Value:  void 

//  

float  Boid: :  checkTerrainColl i 

return  0.0; 
)//end  checkTerrainCollision 


on lamObject*  that) 

to  provide  rudimentary 
ase  not  a  terrain  module 


i  (amObject*  that )  { 
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amArena    Files 


the  module  txt  file  for  tnAi 


Bamboo 1 . Ob 
1 

bbKeyboardModu le 
npsVi  sue '. Module 
aoiHLAAdmm 


// 


//    EXECUTIVE  SUMMARY 

// 

//  File  Name:  module. h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 


//  Description:  This  file  defines  the  global  functions  required  by 
dynamically-linked  library.   How  these  functions  are 
implemented  is  arbitrary,  but  it  is  useful  have  RCS 

//  automate  some  of  the  work. 


// 

//  September  1998,  Masters  Thes 


•ifndef  module 

•define  module 


INCLUDES  AND  EXTERNS 


FUNCTION  PROTOTYPE  SPECIFICATIONS 


•ifdef  cplusplus 

extern  "C"  { 
•endif 

ADMIN_API  const  char  "getModuleName ( ) ; 

ADMIN_API  float  getModuleVersion ( ) ; 

ADMIN_API  const  char  "getModuleDate ( ) ; 

ADMIN_API  const  char  "getModuleText ( ) ; 

ADMIN.API  bool  initModuleU  ; 

ADMIN_API  bool  exitModule ( ) ; 

•ifdef  cplusplus 

); 
•endif 

•endif  //  module 


//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  module. c 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description-  This  file  defines  the  global  functions  required  by  every 

//  dynamically-linked  library.   How  these  functions  are 

//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

//  automate  some  of  the  work. 

// 

It  September  1998.  Masters  Thesis 


//    INCLUDES  AND  EXTERNS 


•include  <stdio.h> 
•include  <stdlib.h>  //  atof 


•include  'module . h* 
•include  " amArena. h* 


DEFINES  i.  FILE  SCOPE  VARIABLES 


st  char  'getModuleName I ) 


return  "amAr 
} 


float  getModuleVersion (] 
{ 

return  1  .Of ; 


nst  char  'getModuleDate () 

{ 

return  "1998/08/01  06:00:48" 


const  char  'getModuleText { ] 
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eturn  "amArena  Terrain  module  --  T  Co  load" 


bool  lnitModulef) 


lnitamArena  f  i  . 
return  1. 


bool  exitModule(] 


return  1. 


EXECUTIVE  SUMMARY 
File  Nam*!-   amArena  I. 

Author   CPT  Stewart  LUee,  Naval  Postgraduate  School 
Description   defines  methods  pertinent  co  module  loading  and  unloading 

Sz-pnemb-r        -    -rr.    Thesis 


■        _amAren 

amAren 


INCLUDES  AND  EXTERNS 


FUNCTION  PROTOTYPE  SPECIFICATIONS 


aid  initamAr^r.a  [  )  , 
Did  exitamArena ( ) , 


INLINED  MEMBEP  FUNCTIONS 


//  

//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  amArena.c 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

II 

II  September  1999,  Masters  Thesis 

//  

//  

//  INCLUDES   AND    EXTERNS 


elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 
elude 


"Rti.hh" 
•npsVisual.h" 
"npsWindow. h* 
"npsViewport  .h" 
"bbMouse  h" 
•bbKeyboard  h* 
•bbEVentResponse. h* 
"bbCallback.h" 
"npsCeometry  .  h* 
•Arena. h- 
"amHLAAdmin  h" 
"admin  .h" 
'amObjeet  h* 


"include  <math . h> 
•include  <CL/gi  h> 

•ifdef  SGI 

•include  "bbSCI.h" 
tendif 


•my Arena ; 
uselnWindow  t ) ; 


Funct  ion  Name :  in: camAren 
Task  initialize  Module 
Return  Value:  void 


prototypes 
id  initKeyboardModule [ ) ; 
id  initVisualKoduleU  ; 


nPointer [myArena) , 

//this  is  a  Terrain  module  so  if  one  already  exists  we  must  delete 
if  (Admin: :ms_Terrain] { 

Admin   unloadModule 1 Admin: :ms_Terrain->getModuleName [) )  \ 
)//end  if 


nitKeyboardModule ( ) ; 

for  future  use 


//  null  my  Arei 
myArena  =  NULL 


//  add  object  to  the  federation 
if (ImyArenal { 

RTI ■  : Object  ID  oid  =  Admin  .  : regis terObjecc (  i  , 

amObject*  tmp  =  Admin  i  :  t mdModuie  !  "amArena*  i  . 

npsCeometry*  arenaPtr  -    npsCeometry: : f indObjecc  CamArena_Geom* ) , 

if  ( 'arenaPtr) ( 

micVisualModuleO. 

) 

myArena  =  (Arena* ) tmp->createOb]ect (oid)  ; 

myArena ->setLoca 10b; ect (RTI: :RTI_TRUE); 

Admin.  :ms_Terrain  =  myArena, 
}//end  if 


update 


//  this  allows  Ar 

if (myArena i ( 

myArena->setUpdateFlag(RTI: :RT:_TRUEl  ; 


it amArena 


est  of  federati 


Function  Name:  exi tamArer.a  [  : 

Task :   does  housekeeping  required  to 

this  is  run  only  once 
Return  Value   void 


the  Module 


// 


void  exitamArena (  i  ( 

bbCallbaekHandler  'callbackHandler, 

bbCallback  'callback; 

bbKeyboa  rd-  key ooa  rd . 

bbEVentResponse"  event Response, 

keyboard  =  bbKeyboard:  getlnstance | I 

II    remove  keyboard  callbacks 
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/'  LoadArena  callback 

keyboard->addEventRei;ponse  (eventResponse)  ; 

«v<-ncR«apons«  =  bbEVent Response   1 1 ndOb ]  <■  c t.  "amArenaER_Terrain "  . 

cal lback  -   bbCal lback  t  indobject i 'amArena.Terrain" ) , 

eventResponse->reinoveCallbo  - 

) 

lelete  callback. 

-  frmote  antObjuetj 

^s_T-rra  in]  { 

//  Function  Nam-   inl tVisualModulet 1 

Admin   rrmov-                    i_Teri  mn->get£nc  icy ID [  )  )  . 

■  Task:   cot  the  geometry  for  the  Arena 

1 

//  Return  Value   void 

r  emove  local  object 

; : ■ 'myArena 1 ( 

void  initVisualMo<!  .  e 

npsGeometry *  tcnp  =  npsGeometry   £  mdOb-ject  i  ,amAr«na_G«om* 

if  Kmpi 

void  initArenaFunc 'bbObject  'object.  bbData  'data): 

de  1  et e  tmp; 

)//end  else 

npsGeometry             "arena; 

//  r«»ovc  che  module  from  module  list 

-nit  geometry 

Admin  :  i  removeModule  1  "ajnArena"  ]  . 

arena  =  new  npsGeometry  1  ini  tArenaFunc  I  ; 

arena->setName ( *amArena_Geom* ) ; 

Admin: -maJTerrain    NULL; 

)   //  end  InitVisualModule 

cout  <<  "exitamArena  *  <<  endl ; 

end  exitamArena 

//  Function  Name   loadArena (bbObject  'object.  bbData  "data) 

//  Task:   function  defined  for  the  loadArena  keyboard  callback 

'   Function  Nan"*:  mi tKeyboardMc d 
Task    add  keyboard  callbacks 

//  Return  Value:  void 

//  Return  Valuer  void 

void  loadArena (bbObject  'object.  bbData  *data)( 

void  initVisualModule (  I  ; 

void  initKeyboardModulel) 

( 

if  (mouselnWindowd  )  ( 

cout  <<  "loadArena*  <<  endl; 

void  escFunc (bbObject  "object,  bbData  "data) . 

void  resetFunc (bbObject  •object.  bbData  "datal; 

i  f  (  !  myArena  )  1 

void  loadArena (bbObject  •object.  bbData  "datal; 

//add  Arena  to  federation  if  does  not  exist 

RTI: :0bjeetlD  Old  ■  Admin  : registerObJecc () . 

bbKeyboard                *  keyboard ; 

amObject*  tmp  =  Admin: : f indModule ( 'amArena* )  ; 

bbEvent Response           * -vent  Response; 

npsGeometry"  arenaPtr  =  npsGeometry  : findobject ( *amArena_Geom' ) ; 

bbCal lback               'callback. 

if  I ' arenaPtr] ( 

initVisualModule ( ) . 

it    get  the  keyboard  device 

) 

keyboard  =  bbKeyboard : :get Instance!  )  ; 

myArena  -  (Arena* ) cmp->createObject (oid) ; 

myArena ->setLoca 10b ject (RTI : :RTI_TRUE) , 

Admin: :ms_Terrain  =  myArena. 

set  up  load  bold  key 

)//end  if 

eventResponse  =  new  bbEventResponse (bbKeyboard: : KEY_T  | 

bbKeyboard: :DOWN_TRANSI ; 

//set  flag  so  Arena  is  updated  and  the  rest  of  the  federation 

eventResponse- > set Name  (  "amArenaER.Terrain" ) ; 

//  will  discover  the  object 

callback  =  new  bbCallback ( ) ; 

if (myArena) ( 

callback->setName ( •amArena_Terrain' )  , 

myArena ->setUpdateF lag (RTI : :RTI_TRUE) ; 

caliback->setFune(loadArena) ; 

) 

eventResponse->addCallbackL-ast  (callback)  ; 

)//end  if 

) 

glBegin (CL_TRIANGLE_STRIP> ; 

(   //start  gl 

for  Ij=0;  j<NUM_VERTS_WIDE;  j»*){ 

//  Function  Name:  mitArenaFunc  (bbObject  "object.  bbData  "data) 

if  (colorTogglel ( 

//  Task:   function  defining  the  Arena  geometry 

colorToggle  =  0; 

//  Return  Value:  void 

glColor3f (O.Of.  O.Of.  l.Of); 

) 
elsel 

void  initArenaFunc (bbObject  "object.  bbData  "data}< 

colorToggle  =  1; 

npsGeometry      "geometry; 

glColor3f (l.Of .  l.Of.  l.Of); 

uint                    displayListNum; 

) 

const  float      CELL_LENCTH  =  SO, 

currVert  =  i'rIUM_VERTS_WIDE  •  j; 

« if def  VISUALCPP 

glVertex3fv (coords (CurrVert) )  ; 

const  uint        NUM_CELLS_LONC  =  10; 

const  uint        NUM_CELLS_WIDE  =  10; 

currVert  =  ( i-l ) -NuH_VERTS_WIDE  •  j. 

•elif  sg: 

glVertex3fv(coordslcurrVert] } ; 

const  uint        NUM_CELLS_LONG  =  SO; 

)//end  for 

const  uint        NUM_CELLS_WIDE  =  SO  ,- 

if  1  NUM_CELLS_WIDE  i.    0x1  )( 

•endif 

if  (colorToggle) 

const  uint       TOTAL_NUH_CELLS  =  NUM_C£LLS_LONG  "  NUM_CELLS_WIDE; 

colorToggle  =  0; 

const  uint       NUM_VERTS_LONG  =  NUM_CELLS_LONC  -  1; 

else 

const  uint       NUM.VERTS.WIDE  =  NUM_CELLS_WIDE  *  1; 

colorToggle  =  1; 

const  uint       TOTAL_NUM_VERTS  =  NUM_VERTS_LONG  "  NUM_VERTS_WIDE; 

) 

uint                     i,  j,  currVert.  currlndex.  currCell; 

)//end  gl 

boo 1                     col orTogg 1 e ; 

glendo  ; 

)//end  for 

GLfloat                   coords [ TOT AL_NUM_ VERTS]  [3]  ; 

GLfloat                 normals [TOTAL_NUM_VERTS] [3] ; 

//  walls  and  ceiling 

GLfloat                   textures [TOTAL_NUM_VERTS] [2] ; 

//North  wall 

glBegin (GL_POLYGON) ; 

glColor3f (0 . 5f . 0 . 5f . 0 . 5 f ) , 

//  Init  Vals 

glVertex3f l-2S.Of.O.0f .  -25. Of); 

colorToggle  =  0; 

glVertexlf (25. Of  .O.Of.  -25. Of]; 

for  (i  =  0;  i<NUM_VERTS_LONG;  l**) { 

glVertex3f (25. Of.  50. Of  .  -25. Of); 

for  |j=0;  j<NUM_VERTS_WIDE;  j")( 

glVertex3f (-2S.0f.S0.0f ,-25.0f> ; 

currVert  =  i "NUK_VERTS_WIDE  *  j; 

glEndo  ; 

//South  wall 

coords [currVert] [0J  =  (CELL_LENCTH  •  ij  - 

glBegin  (GL_POLYGON)  : 

(NU«_CELLS_LONG-CELL_LENGTH-0.5f) ; 

glColor3f (0.6f.0.6f,0.6f); 

coords [currVert] [11  =  O.Of; 

glVertex3f (-25. Of  .O.Of .25. Of ) ; 

coords [currVert] [2]  =  ( -CELL_LENCTH  ■  j]  - 

glVertex3f 125. Of ,0.0f. 25. Of) ; 

(num_cells_w:de*cell_length*o  .  Sf )  .- 

glVertex3f [25. Of. 50. Of. 25. Of); 

normals [currVert] [0]  =  O.Of; 

glVertex3f [ -25 .Of . SO -Of .25. Of); 

normals [currVert] [1]  =  l.Of; 

glEndo  ; 

normals [currVert] [2]  =  O.Of; 

//West  wall 

textures [currVert ]  [0]  =  ( { float) i) / (NUM_VERTS_LONG-l ) ; 

glBegin (GL_POLYGON) ; 

textures [currVert]  [1]  =  (( float ) j )/ (NUM_VERTS_WIDE-1 ) ; 

glColor3f (O.Bf.O.Sf ,0.4f) ; 

>//end  for  j 

glVertex3f 1 -25 .Of .  0 . Of . 25 . Of ) ; 

)//end  for  i 

glVertex3f I -25  Of . 0 .Of . -25 .Of ) ; 

glVertex3f [-25  Of . 50 .Of . -25. Of ) ; 

glShadeModel  (GL_FLAT)  ,- 

glVertex3f (-25. Of. SO. Of. 25. 0f>; 

glEr>d(]  ; 

//East  wall 

colorToggle  =  0; 

glBegin  (GL_ POLYGON)  ; 

glColorlf (0.4f.O.Sf  ,0.8f); 

for  {i  =  0;  i<NUM_CELLS_LONG;  i»*)  ( 

glVertex3f I 2S .Of .  0 . Of . -25 . Of ) ; 
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glVert. 

glVert. 

glVert. 

glEndl ) ; 

Veiling 


x3f  (25  Of .0  .Of .25  .0 
x3£ (25. Of. SO. Of.  25. 
x3f  {2S. Of. SO. Of.  -2S 

wall 


glBegin(CL_POLYGON) , 

glColor3f (0.8f .0    9!    0.8f  )  . 

glVertex3f f-2S.0£.  5C  .0:  ,  -2  5 

glVerr.ex3£(2S.0f.  50 

glVertex3f (2S . Of . SO . Of . 25    0 

glVer:ex3f (-2S.0f. 50 .Of . 25. 
glEndl ) ; 

glShadeModel (GL_SMOOTHI ; 
/micArena-unc 


Return   Value: 


n  Che  co 
ting  boo 


receive  keyboard 


nt  mouseInWmdow{  )  ( 
inc  flag  =  0. 

npsWindow  'window; 

npsViewport  'viewport ; 

window  =  npsWindow . : f indObject ( "AdninWindow" ] ; 

viewport  =  npsViewport  :  :  fmdObjec:  ( 'Admin Viewport'  }  , 

float  x.y; 

x  =  bbMouse  :getX( ) ; 

y  =  bbMouse   getY( ) , 

bbScreen:  : normalizeVal (&x, fcy) ; 


i f  (viewport ->get Window ( i 
flag  =  1; 


sVallnside(x.y) ) ( 


II  EXECUTIVE  SUMMARY 

//  File  Name;  Arena .h 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description:  method  definitions  for  the  Arena  class  -- 

//  Arena  class  represents  the  class  chat  is  implemented  by  the  amAr 

/ /  modu  i  e 

.■ 

//  September  199H.  Masters  Thesis 


include  -Rci  hh* 

include  *npsVec3  f . h" 

include  "npsGeometry . h" 

include  "bbKeyboard ,h' 

mclude  'amObject .  h* 

include  'admir,  h" 

ifndef  ADM:n_API 
Hifdef  VISUALCPP 

•define  ADMIN_API  declspec fdl 1 impor 

ielse 

•define  ADMIN.API 


class  ADMIN_API  Arena  :  public  amOb^ec 


//memeber  variables 

public : 

//  Extent  data  memebers 
static  char*  ms.ModuleNa 


li    Change  flags  fo 


RTI : :Boolean 
RT1: : Boolean 


localFlag; 

updateFlag, 


nly  single  update 


renal  RTI : :0b jeccID   id). 

oid  setLocalObject (RTI : : Boolean) ; 

oid  setUpdateFlag(RTI: :Boolean) ; 


virtual  void  display  (),- 

virtual  amObject*  createObject (RTI : :ObjectID  oid); 

virtual  char'  getModuleName ( ) ; 

vircual  RTI::Boolean  localOb^ect ( ) .- 

virtual  RTI:  (Boolean  lsTerrainl); 

/ /  Methods  acting  on  the  RTI 

virtual  void      sendUpdates I RTI : : Federat lonTime  newTime), 

virtual  void 

sendUpdates I RTI : : Object ID, RTI: : AttnbuteHandleValuePairSeti . 
RTI : : Federat lonTime,  RTI : ; UserSuppl ledTag ) ; 


irtual  void 
RTI : : Feder 


receiveUpdates (RTI : :ObjectID  oid. 

RTI  :  :  Act  nbuteHandleValuePair  Sets,  hvps 
nTime  ft.  RTI :: UserSuppl ledTag  tag). 


virtual  void     sendlnteraction (RTI : : InteractionClassHandle. 
RTI : • ParameterHandleValuePairSeti.  RTI : : Federat lonTime, 
RTI:  : UserSuppl ledTag;  ; 

virtual  void      sendlnteraction ( RTI : : Federat lonTime) ; 

virtual  void  receivelnteraction (  RTI :: InteractionClassHandle 
the  Interaction. 

const  RTI :  :  ParameterHandleValuePairSeti  theparajneters  )  ; 

virtual  void     receivelnteraction [RTI : : InteractionClassHandle, 
RTI : :ParameterHandleValuePairSet4.  RTI: : FederationTime. 
RTI : : UserSuppl l edTag  >  ; 


virtual  RTI- -Boolean  checkColli 
virtual  float  checkTerramColli 
virtual  void  deleteObject ( ) ; 


protected: 

RTI:  :AttributeHandleValuePairSet* 


i  (amObject*  that )  ; 
1  (amObject*  that) ; 


CreateNVPSet ( )  ; 


//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  Arena . c 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

// 

//  Description:    method  definitions    for   the   Arena   class    -- 

/  /  Arena    class    represents    the    class    that    is    implemented    by    the    amAr 

//  module. 


//  September  1996.  Masters  The 


lude 

■RTI.hh- 

lude 

-Arena,  h" 

lude 

'npsGeometry . h* 

lude 

'bbKeyboard. h' 

lude 

<GL/gl.h> 

lude 

•admin . h* 

lude 

"anobjecc -h* 

..-.- 

•amHLAAdjnin  h" 

//  Extent  data  memebers 
char*  Arena: :ms_ModuleNa 


1 1  1 1 1 1 !! 1 1 i  1 1 1  i  1 1 1 1  I  !  1 1 1 1 1 II 
It  Construction/Destruction 
1 1 1 1  i  1 1 1 1 1 1  /  1 1 1 1 1 1 1 1 1  H  1 1 1  1 1 


1 1 1 !  1 1  f  1 1 1 
1 1 1 1 1 1  / 1 1 1 


I  /  1 1 1 1 1 1 1 1 1 1 I 1 1  /  /  1 1 1 1 1 1 1 1 1 1  f 
I  /  1/ 1 1 1 1 1 1 1 1 1 1 1  U 1 1 1 1 1 1 1 1 1 1  / 1 


:  Arena [  RTI : :Obje 
uctor  --  instance 


ena::Arenal  RTI : : ObjectID   id) [ 

cout  «  "Arena  (oid)  *  <<  id  <<  endl  ,- 

setEntitylD(id) , 
npsVec3  f  xx; 
XX. set [O.Of ,0-Of.O.Of ) ; 
setPosition (xx) , 
npsQuatemion  yy; 
setOrientation (yyl ; 

localFlag  =  RTI : : RTI_FALSE; 

updateFlag  =  RTI : :RTI_TRUE; 

Admin:  :ms_Terram  =  this; 
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) //end  constructor 


Function  Nam*-   Ar 

nstructo 

Return  Valu**   V01 


ona  a  •  i 
'end  default  c 


age  in  ModuleAnay 


Function  Name   -Are 
Task    destructor 
Return  Va 


-Ar« 


i 


cout    <<     "The    arena    geometry   was    just    del* 

<<     "I!     you    deleted    Ch«    terrain    ignore    message\n* 
<<     'else   a    tederate    JUSC    qui:    the    federat ion Vn* 
<<    -PUSH     T  to  display    terrain" 
•  •    Midi, 

npsCeometry*    tmp    =    npsGeometry : : f indObject ( *amArena_Geom* 

j-.-r-    tmp. 


)    /end  destructo 


It    Function  Name:  sendUpdates IRTI  :ObjectID  oid. 
RT:  ;  AttnbuteHandleValuePairSetl.  ta. 

RTI ■  FederationTime  ft.  RTI ; : UserSuppl ledTag  tag] 
ft    Task   not  implemented  in  this  module  --  pure  virtual  fu 
/'     have  definition 
/   Return  Value:  void 


id  Arena: isendUpdates [RTI : :Ob:ectID  oid.  RTI  :  :  At tributeHandleValuePairSetfc 
RTI ■ . FederationTime  ft.  RTI : : UserSuppliedTag  tag) 


/>  Function  Name.  sendUpdates IRTI :: FederationTime 
//  Task;:  send  handle  value  pair  Co  rti  for  update 
,','  Return  Value:  void 


ndUpdates (RTI : : FederationTi 


it (updat-Flag I  i 

RTI:  AttributeHandleValuePairSef  pNvpSet  ;  CreateNVPSet ( ) ; 

Adfflin   aendEntltyUpdate  '  get Entity 10 1 )  . "pNvpSet .  getModuleName! 1  )  ; 

updateFlag  -    RTI  :: RTI_FALSE. 

- 

'  end  sendUpda  t  es 


/  f 


/.'  Function  Name:  receiveUpdates I  RTI :  Object  ID  oid. const 

PTI   AttributeHandleValuePairSeti.  theAttnbut-  . 

it  RTI:  :  FederationTime  theTime.  RTI   'J.-;<-r  Suppl  iedTag  the 

fl    Task;   decodes  HVP  from  RTI  for  this  object 

,■ '/  Return  Value:  void 


void  Arena  : receiveUpdates (  RTI : :0bjectID  oid. const 
RTI  :  :AttnbuteHandleValuePairSetfc  theAttnbutes. 

RTI : : FederationTime  theTime.  RTI   UserSuppl ledTag  theTag) { 

RTI  :  ; AttributeHandle  attrHandle. 

unsigned  long        va lue Length, 

//  We  need  to  iterate  through  the  Attr ibuteHandleValuePairSet 
//  to  extract  each  Attr ibuteHandleValuePair .   Based  on  the  type 
//  specified  i  the  value  returned  by  getHandlel]  )  we  need  to 
//  extract  the  data  frlom  the  buffer  that  is  returned  by 

//  getValuet) . 

for  [  unsigned  int  i  =  0;  l  <  theAttr lbutes . size ! i ,  i**  ) 


[ 


attrHandle  -  theAttr lbutes .getHandle [  i  ); 

if  I  attrHandle  ==  Admin : : getPosit lonAttrHandle I ] 

{ 

npsVec3  f  tmp. 

theAttributes  .getValue  [  i.  (char  •  )  *.tmp,  valueLe 

setPosit ion (tmp) ; 


)//  end  for 
) //end  recevieUpdate 


//  Function  Name   rece  welnteract ion (RTI  : Interact lonClassHandle  ich, 

//     RTI : : ParameterHandleValuePairSetfc  phvps.  RTI :: FederationTime  ft 

//     RTI :  UserSuppliedTag  tag) 

//  Task:   not  implemented  in  this  module  --  pure  virtual  function  mus 

//     have  definition 

//  Return  Value:  void 


id  Arena :  : receive Interact  ion [RTI :  : Interact lonC la ssHandle  ich, 

RTI : : ParameterHandleValuePairSett  phvps,  RTI :: FederationTime  ft 
RTI :: UserSuppl iedTag  tag) 


eterHandleValuePairSeti.  theParam 
is  module  --  pure  virtual  functi 


ivelnteraction (  RTI: : InteractionClassHandle  thelnteroction, 
st  RTI  :  :  ParameterHandleValuePairSets.  theParameters  ] 


II 

Functi< 

n  Name ■  re 

ceive 

!nt< 

thelnteraction. 

II 

const 

RTI: 

1  a 

II 

Task: 

not  implem 

ented 

in 

II 

have  definitio 

/I 

Return 

Value:  voi 

d 

void  Arena :  : 


()//end  receivelnt 


//  * 

//  Function  Name:  sendlnteractic 
Task:   not  implemented  in  thi 
it           have  definition 
//  Return  Value:  void 
//  


KRTI:  federation 
;  module  --  pure 


void  Are 
t) 


// 


sendlnteracti 


l(RTI  -FederationTi: 


//  Function  Name :  sendlnteracti on (RTI : : InteractionClassHandle  ihc, 

//     RTI  :  rParameterHandleValuePairSett  phvps.  RTI :: FederationTime  ft. 

//    RTI :: UserSuppl iedTag  tag) 

//  Task:   not  implemented  in  this  module  --  pure  virtual  function  must 

ft  have  definition 

//  Return  Value:  void 

//  

void  Arena: : sendlnteraction (RTI : : InteractionClassHandle  ihc, 

RTI:  :ParameterHandleValuePairSetfc  phvps.  RTI:  : FederationTime  ft, 
RTI: : UserSuppl iedTag  tag) 


//  Function  Name:  CreateNVPSet ( ) 

//  Task:   creates  HVP  set  pertinent  to  this  object 

//  Return  Value:  AttributeHandleValuePairSef 


RTI: :AttributeHandleValuePairSet*  Arena: ; CreateNVPSet () ( 

RTI :  : AttributeHandleValuePairSef  pArenaAttributes  =  NULL; 


//  Make  sure  the  RTI  Ambassador 
if  I  Admin: :ms_rtiAmb  } 


//  Set  up  the  data  structure  required  to  push  this 
//  objects's  state  to  the  RTI. 

RTI ;  ;Ob;jectIDcount  numAt tributes  [1)  ; 

pArenaAttributes  =  RTI : :AttributeSetFactory : :create (  numAt tributes  J; 

pArenaAttributes->add(  Admin: :getPositionAttrHandle ( ) , 
(char*)  (.position, 
sizeof [npsVec3f)  ) ; 


return  pArenaAttributes; 
)//end  CreateNVPSet!) 


//  Function  Name:  display!) 

//  Task:   not  implemented  in  this  module 

//     have  definition 

//  Return  Value:  void 


id  Arena; :display() { 
/  end  display 


//  Function  Name:  createObject 'RTI : :ObjectID  oid) 

//  Task :   creates  an  object  and  returns  a  pointer  to  it 

//  Return  Value:  amObjecf 


amObjecf  Arena  :  .createObject  (RTI :  :0bject  ID  oid)  { 


Arena"  tmpArena  =  new  Arena (oid); 
return  (amObj  ecf  )  tmpArena  , 


)//end  createObject 


//  Function  Name:  getModuleName  I  ) 

//  Task:   accessor  method  for  module 

//  Return  Value:  char* 


char"  Arena: : getModuleName ( ) { 

return  Arena :  :ms_ModuleNaine; 
)//  getModuleName 
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"unction  Name   setLocalObiect [ RTI :: Boolean  flag] 
Task,   set  the  object  as  local  or  not 
Return  Value   void 


:?:  rti_true. 

ce;ling  check 

hat-  ►exposition  i  .  get  (1]  >  40.0*1  { 
flag  =  RT: : :RTI_TRUE. 


void  Arena:  setLocalObject (RTI   Boolean  £lagi( 

localFlag  =  Hag, 
}.'.'end  setLocalObject 


North  wall  check 

that->getPosit  .       i- 
flag  -    RTI. :RTI_TRUEj 


.  Funct ion  Name   local Object  1  I 
'/  Task   accessor  method  for  local  object  flag 
//  Return  Value   Boolean 


RTI. -Boolean  Arena   localObject I ) ( 

return  localFlag, 
)//end  local Object 


south  Wall  cneck 
s<  if { fthat->getPosition() ]  get(2)  >  24.0f){ 
flag  =  RTI   PT:_TRU£. 

West  wall  check 

se  if [  (that->getPosition( ]  i   .get  :0)  * 
'lag  =  RTI. :PTI_TRUE, 

East  wall  check 
Lse  if f (that->getpositionl) ) .get (0)  >  24  0f)( 

flag  =  RTI : :RT1_TRU£, 


Function  Name:  isTerrain;] 

Task:   informs  amHLAAdmin  whether  the  object  is  a  terrain  obje 

Return  Value:  Boolean 


return  flag. 
/end  checkCollisi 


RTI;:Boolean  Arena   isTerrain i ! { 

return  RTI'  RTI_TRUE, 
)//end  isTerrain 


Function  Name   checkTerramColl  1 
Task    returns  y  value  for  terra 

collision  detection 
Return  Value,  void 


iiamOb)ecf  that) 
to  provide  rudime 


//  Function  Name:  set UpdateFlag (RTI  :Booiear,  flag: 

/  /  Task    sets  update  f  Lag  —  used  in  send  updates 
//     transmit  a  HVF  or  not 

;/  Return  Value   void 


decide  whether 


at  Arena  :  ?  checkTerramCol  1  ision  lamGbject  *  that  | 
float  yPosition  =  0.0, 


if;! t ha t - >get Posit  ion ( )  )  -get  III  <    0 . S  I  ( 
yPosition  =0.5, 


void  Arena :: setUpdateFlaglRTI : .Boolean  flag){ 

updateFlag  =  f  lag ; 
)//end  setUpdateFlag 


return  yPosit 
/end  checkTerr 


//  Function  Name   checkColl ision (amObject •  that) 

/.'  Task.   returnds  true  if  there  is  a  collision  with  this  obje 

//  Return  Value'  Boolean 


Function  Name:  delet eOb^ect t  I 
Task:  remote  delete  function 
Return  Value;  void 


RTI : : Boolean  Arena .  checkColl ision (amObject *  that ) ( 
RTI:  boolean  flag  =  RTI :  :RTI_FALSE; 


//  floor  ckeck 

if  (  :that->getPosition(l  )  .get  (II  <  O.SfK 


id  Arena : :deleteObject I ) ( 
delete  this; 


the  module . txt  file  for  amPageModule  module 


Bambool . Ob 


amPageModule    Files 


bbKeyboardModule 

bbMouseModule 

npsVisualModule 
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EXECUTIVE  SUMMARY 
File  Nam-   modulo. h 

Author:  CPT  Stewart  .  .   Postgraduate  School 

Description   defines  mf.hods  p-r:inrn^  to  module  loading  and  unloading 


t nde I    modu 1 e 

<if  fine  modu  1 e 


FUNCTION  PROTOTYPE  SPECIFICATIONS 

ifdef  cplusplus 

xtern  -C"  ( 

endif 

ADMIN_API  const  char  "getModuleName ( I , 
ADMIN_API  float  getModuleVersion ; I . 
ADKIN_API  const  char  "getModuleDat e ( i . 
ADMIN_API  const  char  "getModuleText I ) ; 
ADMIN_API  bool  lnitModule ( ) , 
ADMIN_API  bool  exi tModule I ) ; 

•ifdef  cplusplus 

). 

•endif 

•endi £    //    module 


ft  EXECUTIVE    SUMMARY 

// 

■  Fi>  Name  i  module  c 

// 

/ /  Author   CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

ft  September  1999.  Master;  Thesis 

'  

//  INCLUDES  AND  EXTERNS 


•  include  "module .  h" 
•include  "amPageModule  ft" 


const  char  "getModuleName ( ) 
( 

return  "amPageModule" , 
J 

float  getModuleVersion { ) 
{ 

return  1.0; 
} 

const    char    "getModuleDat- ( ) 
{ 

return    "1999/09/01    06:05:-;8". 
) 

const    char    'getModuleText  :  ) 
{ 
return    "This   module   enables   the   user   to  dynamically  page  modules    in\n 

and   out    of    the  system  via    pressing   the   L  and  U  keys   respectively" 


bool    lnitModulef) 


mitamPageModule!  }  , 
return   1; 


bool    exitModulel  ) 
( 
return    1, 


//  EXECUTIVE    SUMMARY 

// 

/  /  Fi  le  Name  -.    amPageModule  .  h 

// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

//  Description:  defines  methods  pertinent  to  module  load 

// 

//  September  1998,  Masters  Thesis 


// 


•  i  fndef  _ amPageModule 
•define  _amPageModule 


FUNCTION  PROTOTYPE  SPECIFICATIONS 


void  initamPageModule ( )  ; 
•endif  //  _myKeyModule 


// 


//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  amPageModule .c 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

// 

//  September    1996,    Masters  Thesis 

//  INCLUDES    AND    EXTERNS 


lude 

*  amPageModule . h* 

lude 

-bbKeyboard.h" 

lude 

•bbEventResponse . h 

lude 

■bbCallback.h- 

lude 

•bbModule.h* 

lude 

-bbKouse.h- 

lude 

"npsWmdow.  h* 

elude   "npsViewpor 


Function  Name:    initamPageModule [ J 
Task:      initialize  Module    --    this    i 

sets   up    keyboard   ca 1 lbacks 
Return  Value:    void 


void   initamPageModule!) ( 

void   loadFunc (bbOb]ect    -object.    bbData    'data) ; 
void  unloadFunc IbbObject    "object,    bbData    "data); 

bbKeyboard  "keyboard. 

bbEvent Response       'even t Response; 
bbCallback  -callback; 

keyboard    =    bbKeyboard: :getlnstance (1 ; 

//    load   module    key 

eventResponse    =    new   bbEventResponse (bbKeyboard :: KEY_L    | 
bbKeyboard: :CTRL_MASK     |    bbKeyboard: ; DOWN_TRANS > ; 
callback   =    new  bbCallback  ()  ,- 
callback->setFunc( loadFunc)  ; 
entResponse->addCallbackLast (callback) ; 
keyboard- >add£ventResponse [eventResponse! ; 

//  unload  module   key 

eventResponse    =    new   bbEventResponse (bbKeyboard: :KEY_U    | 
bbKeyboard: :CTRL_KASK    |    bbKeyboard : :DOWN_TRANS) ; 


70 


callback  =  new  bbCallback ( : . 

ral  lback->setFunc (unloadFunc)  . 

event  Response- >addCal IbackLast (callback)  . 

keyboard- >add£vent Response [event Response  1 

'end  initamPageModule 


//  Function  Name  ivadFunc ( 
/■  Task  callback  function 
//  Return  Value,  void 


loads  modules 


adFunc  (bbOb;ject  'object.  bbData  *datai( 
mouse  InWm  do  w | ; ; 

moduleName  |*>4)  . 
-ptr, 

ouselnWindowl ) ) ( 

out  <<    'LOAD:Please  enter  the  module"s  n 
in  >>  moduleName . 
out  <<    endl; 


[  ! strncmp (moduleName .  *http 
ptr  =  moduleName  -  7 ; 
ptr  =  strrchrlptr,  '/');   / 
if  [!pcrl ( 

cout  <<  "   myDynamicPageModule   Bad  c 


.  7)  )  ( 

skip  over  http: // 
ke  sure  url  well  formed 


endl. 

\*http; 
http- / / 


endl; 

N'http: 
http: / / 


cout  <<  *   myDynamicPageModule :  URLs 
/<host>[/path) /moduleName \ *  *  <<  endl ; 

cout  <<  *   myDynamicPageModule   Example   bambo 
at sen . net / Bamboo/ Modules /my RemoteModule*  <<  endl . 


and  line  parameter 
t  be  formatted  as 


nd : . 


) 

*ptr  =  " \0 ' ; 
if  (  Mptr-ll 


effi 


=  =  '\0')t  II    module  can  not  be  index.html' 
cout  <<  •   myDynamicPageModule :  Bad  command  line  par a me 

cout  <<  "   myDynamicPageModule :  URLs  must  be  formatted 
<host> [ /path) ZmoduleNameV"  "  «    endl , 

cout  <<    *   myDynamicPageModule :  Example :  bamboo 
'.sennet  /  Bamboo /Modules/myRemoteModule"  <<    endl ; 

cout  <<  endl. 


) 


if  ('bbModule 
-ptr  =  " /' 


d[ptr-l.  moduleName] ) ( 

<  *   myDynamicPageModule:  Unable  to  load  * 

<  endl. 

st  already  be  on  disk 


• bbModule  . load [moduleName 

out  <<  "   myDynamicPageModt^  le   Unable 


moduleName 


)  .  '  end  1 1 
I  ■  'end  loadFun 


■'  Function  Name   loadFunc : ) 
■  Task    callback  function  that  unloads  modui-:. 
/  Return  Value:  void 


old  unloadFunc (bbQb;ect  'object.  bbData  'dotal  t 
mt  mouse InWindow ( )  . 

char       moduleName  ['j 4  ;  , 
bbModule  'module, 

if (mouselnWindow) ] i [ 

cout  <<  -UNLOAD:Please  enter  the  module's  name 
cin  >>  moduleName, 
cout  <<  endl; 

module  =  bbModule   f mdObject [moduleNamei . 
if  [ -module] { 

cout  <<  *   myDynamicPageModule :  specified  module 
is  not  currently  loaded. .. ignoring*  <<    endl. 

return, 
) 

if  [ ! bbModule; :unload(module: | ( 

cout  <<  *   myDynamicPageModule:  Error  unloading 


uleName 
<  endl. 


/end  if 

end  unloadfu 


Return  Valu 


representing  boolean 


selnWindowO  ( 
flag  =  0, 


npsWindow 

npsViewporc 


window  =  npsWindow : : f indObject { "AdminWindow* )  , 
viewport  =  nps Viewport :  : f indObject ( 'AdmmViewport  * 
float  x.y; 

X  =  bbMouse: :getX ( ) ; 
y  =  bbMouse: :getYt ) ; 
bbScreen:  :  norma lizeVal  (i.x.s.y)  ; 

if (window) { 

if  (viewport->getWmdow(  )  ->isVal Inside  fx.  yl  )  ( 
flag  =  1; 


return  flag; 
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APPENDIX  C:      GLOSSARY 

•  attribute 

•  A  named  portion  of  an  object  state. 

•  event 

•  A  change  of  object  attribute  value,  an  interaction  between  objects,  an 
instantiation  of  a  new  object,  or  a  deletion  of  an  existing  object  that  is 
associated  with  a  particular  point  on  the  federation  time  axis.  Each  event 
contains  a  time  stamp  indicating  when  it  is  said  to  occur  (also  see  definition 
of  message). 

•  federate 

•  A  member  of  a  HLA  Federation.  All  applications  participating  in  a 
Federation  are  called  Federates.  In  reality,  this  may  include  Federate 
Managers,  data  collectors,  live  entity  surrogates  simulations,  or  passive 
viewers. 

•  federation 

•  A  named  set  of  interacting  federates,  a  common  federation  object  model, 
and  supporting  RTI,  that  are  used  as  a  whole  to  achieve  some  specific 
objective. 

•  federation  execution 

•  The  federation  execution  represents  the  actual  operation,  over  time,  of  a 
subset  of  the  federates  and  the  RTI  initialization  data  taken  from  a 
particular  federation.  It  is  the  step  where  the  executable  code  is  run  to 
conduct  the  exercise  and  produce  the  data  for  the  measures  of  effectiveness 
for  the  federation  execution. 

•  Federation  Object  Model  (FOM) 

•  An  identification  of  the  essential  classes  of  objects,  object  attributes,  and 
object  interactions  that  are  supported  by  an  HLA  federation.  In  addition, 
optional  classes  of  additional  information  may  also  be  specified  to  achieve  a 
more  complete  description  of  the  federation  structure  and/or  behavior. 

•  interaction 

•  An  explicit  action  taken  by  an  object,  that  can  optionally(within  the  bounds 
of  the  FOM)  be  directed  toward  other  objects,  including  geographical 
areas,  etc. 

•  message 

•  A  data  unit  transmitted  between  federates  containing  at  most  one  event. 
Here,  a  message  typically  contains  information  concerning  an  event,  and  is 
used  to  notify  another  federate  that  the  event  has  occurred.  When 
containing  such  event  information,  the  message's  time  stamp  is  defined  as 
the  time  stamp  of  the  event  to  which  it  corresponds.  Here,  a  "message" 
corresponds  to  a  single  event,  however  the  physical  transport  media  may 
include  several  such  messages  in  a  single  "physical  message"  that  is 
transmitted  through  the  network. 
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•  model 

•  A  physical,  mathematical,  or  otherwise  logical  representation  of  a  system 
entity,  phenomenon,  or  process.  [DoD  5000.59] 

•  object 

•  A  fundamental  element  of  a  conceptual  representation  for  a  federate  that 
reflects  the  "real  world"  at  levels  of  abstraction  and  resolution  appropriate 
for  federate  interoperability.  For  any  given  value  of  time,  the  state  of  an 
object  is  defined  as  the  enumeration  of  all  its  attribute  values. 

•  object  model 

•  A  specification  of  the  objects  intrinsic  to  a  given  system,  including  a 
description  of  the  object  characteristics  (attributes)and  a  description  of  the 
static  and  dynamic  relationships  that  exist  between  objects. 

•  object  model  framework 

•  The  rules  and  terminology  used  to  describe  HLA  object  models. 

•  object  ownership 

•  Ownership  of  the  ID  attribute  of  an  object,  initially  established  by  use  of 
the  Instantiate  Object  interface  service.  Encompasses  the  privilege  of 
deleting  the  object  using  the  Delete  Object  service.  Can  be  transferred  to 
another  federate  using  the  attribute  ownership  management  services. 

•  Runtime  Infrastructure  (RTI) 

•  The  general  purpose  distributed  operating  system  software  which  provides 
the  common  interface  services  during  the  runtime  of  an  HLA  federation. 

•  simulation 

•  A  method  for  implementing  a  model  over  time.  Also,  a  technique  for 
testing,  analysis,  or  training  in  which  real-world  systems  are  used,  or  where 
real- world  and  conceptual  systems  are  reproduced  by  a  model. 

•  Simulation  Object  Model  (SOM) 

•  A  specification  of  the  intrinsic  capabilities  that  an  individual  simulation 
offers  to  federations.  The  standard  format  in  which  SOMs  are  expressed 
provides  a  means  for  federation  developers  to  quickly  determine  the 
suitability  of  simulation  systems  to  assume  specific  roles  within  a 
federation. 

•  time  management 

•  A  collection  of  mechanisms  and  services  to  control  the  advancement  of 
time  within  each  federate  during  an  execution  in  a  way  that  is  consistent 
with  federation  requirements  for  message  ordering  and  delivery. 
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